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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list