On Mon, Apr 04, 2011 at 09:19:36AM -0500, Anthony Liguori wrote:
On 04/04/2011 08:16 AM, Daniel P. Berrange wrote:
>That doesn't really have any impact. If a desktop user is logged
>in, udev may change the ownership to match that user, but if they
>aren't, then udev may reset it to root:disk. Either way, QEMU
>may loose permissions to the disk.
Then if you create a guest without being in the 'disk' group, it'll
fail. That's pretty expected AFAICT.
We don't *ever* want to put QEMU in the 'disk' group because
that gives it access to any disk on the system in general.
But with libvirt today, when you launch a guest, your security
context doesn't matter and there's no way you can control what
context the guest gets. libvirt is essentially creating it's own
authorization mechanism. Supporting ACLs goes much further down
that path.
>>How much of a leap would it be to spawn a guest with the credentials
>>of the user that created/defined it? Or better yet, to let the user
>>be specified in the XML.
>That's a completely independent RFE which won't fix this issue in
>the general case.
I think it really does.
Nope it doesn't.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|