From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCWJK-0003hD-TY for qemu-devel@nongnu.org; Fri, 14 Sep 2012 09:52:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCWJE-0007Bd-Ry for qemu-devel@nongnu.org; Fri, 14 Sep 2012 09:51:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCWJE-0007BQ-Jy for qemu-devel@nongnu.org; Fri, 14 Sep 2012 09:51:52 -0400 Date: Fri, 14 Sep 2012 14:51:21 +0100 From: "Daniel P. Berrange" Message-ID: <20120914135121.GB6819@redhat.com> References: <1345068639-19528-1-git-send-email-mhcerri@linux.vnet.ibm.com> <504F7F52.2010809@linux.vnet.ibm.com> <20120914084051.GA7208@redhat.com> <505331AE.8080509@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <505331AE.8080509@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [libvirt] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Corey Bryant Cc: Anthony Liguori , bryntcor@us.ibm.com, libvir-list@redhat.com, mprivozn@redhat.com, qemu-devel , Marcelo Cerri , gcwilson@us.ibm.com, eblake@redhat.com 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 :|