On Fri, Sep 14, 2012 at 09:31:26AM -0400, Corey Bryant wrote:
On 09/14/2012 04:40 AM, Daniel P. Berrange wrote:
On Tue, Sep 11, 2012 at 02:13:38PM -0400, Corey Bryant wrote:
Are there any other requirements that need to be taken care of to enable execution of QEMU guests under separate unprivileged user IDs (ie. DAC isolation)?
At this point, this patch series (Per-guest configurable user/group for QEMU processes) is upstream, allowing libvirt to execute guests under separate unprivileged user IDs. Additionally, the QEMU bridge helper series is upstream, allowing QEMU to allocate a tap device and attach it to a bridge when run under an unprivileged user ID (http://www.redhat.com/archives/libvir-list/2012-August/msg00277.html).
Is there any other feature in QEMU that requires QEMU to be run as root?
Well those features you mention are for two separate issues. When running libvirt privileged (qemu:///system), QEMU was already run as non-root (qemu:qemu). The per-guest user/group was just making sure that QEMU VMs were isolated from each other using user IDs. Since libvirtd is running privileged, it can either set permissions or open things on QEMU's behalf. All this side of things really works already.
Ok good. This is really what I was getting at and you answered my question. So we now have DAC isolation of QEMU guests when running with the qemu:///system URI and there shouldn't be any issues running unprivileged guests from a privileged libvirt.
The TAP device bridge helper is something that's needed when running libvirtd itself unprivileged (eg the per user qemu:///session libvirtd). In this case libvirtd can't access privileged resources at all, hence the setuid TAP helper was required.
Ah, that's right, the bridge helper is really only benefiting libvirt when running with the qemu:///session URI.
Is there a desire to get to a point where libvirt can do everything under a session URI that it can do today under a system URI? Then libvirt and guests could all run unprivileged. I'm sure it's a lot of work.. I'm just asking. :)
Well if you want to give a VM a raw block device someone/thing needs to be running privileged to set an ACL on the device to le the unprivileged VM use it. Similarly for PCI device passthrough. Traditionally in the qemu:///system case, libvirt can deal with this. In a qemu:///session case the sysadmin would have had to setup ACLs/permissions on the devices / files ahead of time. 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 :|