From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N64qm-00067k-AK for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:06:16 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N64qh-00066o-ID for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:06:16 -0500 Received: from [199.232.76.173] (port=54608 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N64qh-00066l-Fi for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:06:11 -0500 Received: from e9.ny.us.ibm.com ([32.97.182.139]:58444) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N64qh-0005JA-4a for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:06:11 -0500 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e9.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nA5G1QaO032195 for ; Thu, 5 Nov 2009 11:01:26 -0500 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nA5G69Wg083464 for ; Thu, 5 Nov 2009 11:06:09 -0500 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nA5G7bZQ019899 for ; Thu, 5 Nov 2009 09:07:38 -0700 Message-ID: <4AF2F7E9.50300@us.ibm.com> Date: Thu, 05 Nov 2009 10:06:01 -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> <4AF2E7CE.8010506@us.ibm.com> <4AF2EB17.8090202@redhat.com> In-Reply-To: <4AF2EB17.8090202@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: >> 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. 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. 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. 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. -- Regards, Anthony Liguori