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

[Corey Bryant]

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

> So I guess this is a roundabout way of saying that I'm not really
> clear what you're asking about ? If you're using qemu:///system
> there has never been any problem with running QEMU unprivileged.
> When using qemu:///session you're obviously limited to whatever
> resources the user is allowed to access.

--
Regards,
Corey Bryant