From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N6502-0001or-J8 for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:15:50 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N64zx-0001nG-6V for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:15:49 -0500 Received: from [199.232.76.173] (port=48842 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N64zw-0001n1-T8 for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:15:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:13286) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N64zv-0006kS-TW for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:15:44 -0500 Message-ID: <4AF2FA2A.4060500@redhat.com> Date: Thu, 05 Nov 2009 18:15:38 +0200 From: Avi Kivity 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> <4AF2E7CE.8010506@us.ibm.com> <4AF2EB17.8090202@redhat.com> <4AF2F7E9.50300@us.ibm.com> In-Reply-To: <4AF2F7E9.50300@us.ibm.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: Anthony Liguori Cc: Mark McLoughlin , Arnd Bergmann , Dustin Kirkland , Juan Quintela , qemu-devel@nongnu.org, Michael Tsirkin On 11/05/2009 06:06 PM, Anthony Liguori wrote: > Avi Kivity wrote: >>> If we make this easy for management software to do, they're more >>> likely to do the right thing. >> >> But we're forcing our style of security management on them. How to >> store permissions is the management system's job (and for a clu^Houd, >> it will typically be stored in a central database, not be scattered >> around /etc). >> >> Again, IMO we should stick to making a guest work, and leave all the >> glue to management. > > That's short sighted. If we just focus on "making a guest work" we'll > end up with crappy interfaces that cripple management tools. Only with management tools that cripple themselves. It's pretty easy to get unprivileged bridging with -net tap; it's just that libvirt hadn't gotten around to it yet -- see Dan's comment. Are you going to take on every libvirt deficiency and push it into qemu? > If users are constantly struggling to do even the simplest things with > qemu, then it doesn't matter how well our "guest works". No one will > use it. That's not the case today, even with virt-manager. > I think we absolutely have to think about the full stack and how all > the pieces interact. There are definitely problems in the stack right > now. Security is the one I'm trying to address in this series. If > you cannot launch a reasonable configured qemu from the command line > as an unprivileged user, there's really no hope that we can expect a > management tool to do that. I'm almost offended on Dan's behalf. > Again, there are no shortage of existence proofs of this (beyond > libvirt). I suspect there isn't a management tool out there that does > the right thing today. RHEV-H launches guests as unprivileged users; the management daemon is also unprivileged. -- error compiling committee.c: too many arguments to function