From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N64bl-0001Hy-30 for qemu-devel@nongnu.org; Thu, 05 Nov 2009 10:50:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N64bf-0001AS-Jy for qemu-devel@nongnu.org; Thu, 05 Nov 2009 10:50:44 -0500 Received: from [199.232.76.173] (port=49939 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N64bf-0001AI-Dj for qemu-devel@nongnu.org; Thu, 05 Nov 2009 10:50:39 -0500 Received: from e2.ny.us.ibm.com ([32.97.182.142]:33604) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N64be-0002en-Up for qemu-devel@nongnu.org; Thu, 05 Nov 2009 10:50:39 -0500 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e2.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nA5FgtYL008893 for ; Thu, 5 Nov 2009 10:42:55 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nA5FoaWH610444 for ; Thu, 5 Nov 2009 10:50:36 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nA55nLEE026798 for ; Thu, 5 Nov 2009 00:49:22 -0500 Message-ID: <4AF2F449.6040308@us.ibm.com> Date: Thu, 05 Nov 2009 09:50:33 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu References: <1257294485-27015-1-git-send-email-aliguori@us.ibm.com> <4AF2E247.3090409@redhat.com> <4AF2E2E3.1030600@redhat.com> <4AF2E638.8050302@us.ibm.com> <4AF2E9CA.4060008@redhat.com> In-Reply-To: <4AF2E9CA.4060008@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Mark McLoughlin , Arnd Bergmann , Dustin Kirkland , Juan Quintela , qemu-devel@nongnu.org, Michael Tsirkin Avi Kivity wrote: >> The model you're advocating (privileged process handing over a fd) is >> not as secure because it requires that the management daemon runs as >> a privileged user. > > Or it can acquire an fd from a privileged helper and pass it on or > conjure it some other way. So qemu should not be allowed to interact with a privileged helper on it's own? I can't tell what your objection here is. Do you want people to just not use qemu directly from the command line? >> There's nothing about this that prevents the use of a management >> framework. In fact, had this existed when libvirt was first written, >> I'd hope libvirt would have used this mechanism instead of fd >> inheritance. >> >> Management software is really just another user. We really want >> management software to run unprivileged as much as possible. > > I'd like to see qemu confined to managing a single guest and not > expand to system management. We have enough to do without taking over > management systems and security. > > Bridged network configuration is painful now, but only for a handful > of users (us developers). For the vast majority it is handled behind > their back by management, which has to deal with a bunch of privileged > stuff anyway (assigned LVM volumes, assigned pci and usb devices, > setting up the bridge, large pages, guest priorities). Why are we > adding code to benefit so few people, many of whom don't really use > qemu as users? I strongly disagree with the way you separate users who use management software from people who invoke qemu directly. libvirt and virt-manager are existence proofs that management software heavily relies on the defaults and mechanisms we establish within qemu. We can say all we want about how management software should do things but the best way is to make it easy for them to do the right thing. -- Regards, Anthony Liguori