From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41908) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCX80-0006oZ-Qa for qemu-devel@nongnu.org; Fri, 14 Sep 2012 10:44:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCX7y-0000ta-Te for qemu-devel@nongnu.org; Fri, 14 Sep 2012 10:44:20 -0400 Received: from e38.co.us.ibm.com ([32.97.110.159]:33351) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCX7y-0000tE-Mn for qemu-devel@nongnu.org; Fri, 14 Sep 2012 10:44:18 -0400 Received: from /spool/local by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 14 Sep 2012 08:44:16 -0600 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 8D08E19D803E for ; Fri, 14 Sep 2012 08:44:13 -0600 (MDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q8EEiCZ3185696 for ; Fri, 14 Sep 2012 08:44:12 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q8EEiBpj011937 for ; Fri, 14 Sep 2012 08:44:11 -0600 Message-ID: <505342B8.2070606@linux.vnet.ibm.com> Date: Fri, 14 Sep 2012 10:44:08 -0400 From: Corey Bryant MIME-Version: 1.0 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> <20120914135121.GB6819@redhat.com> In-Reply-To: <20120914135121.GB6819@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Anthony Liguori , libvir-list@redhat.com, mprivozn@redhat.com, qemu-devel , eblake@redhat.com, gcwilson@us.ibm.com, Marcelo Cerri On 09/14/2012 09:51 AM, Daniel P. Berrange wrote: > 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. Perhaps these are things that could eventually be taken care of by a setuid root helper with reduced capabilities, allowing libvirt to run unprivileged. -- Regards, Corey Bryant