Re: [Qemu-devel] [libvirt] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes

[Daniel P. Berrange]

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 :|