From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N63PN-0005eo-4v for qemu-devel@nongnu.org; Thu, 05 Nov 2009 09:33:53 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N63PI-0005a3-UT for qemu-devel@nongnu.org; Thu, 05 Nov 2009 09:33:52 -0500 Received: from [199.232.76.173] (port=57939 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N63PI-0005Zp-Q4 for qemu-devel@nongnu.org; Thu, 05 Nov 2009 09:33:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37257) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N63PI-0006Tw-Az for qemu-devel@nongnu.org; Thu, 05 Nov 2009 09:33:48 -0500 Message-ID: <4AF2E247.3090409@redhat.com> Date: Thu, 05 Nov 2009 16:33:43 +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> In-Reply-To: <1257294485-27015-1-git-send-email-aliguori@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/04/2009 02:28 AM, Anthony Liguori wrote: > This series solves a problem that I've been struggling with for a few years now. > One of the best things about qemu is that it's possible to run guests as an > unprivileged user to improve security. However, if you want to have your guests > communicate with the outside world, you're pretty much forced to run qemu as > root. > Only is you run an unmanaged system. > At least with KVM support, this is probably the most common use case which means > that most of our users are running qemu as root. That's terrible. > Most of our users run managed systems. > We address this problem by introducing a new network backend: -net bridge. This > backend is less flexible than -net tap because it relies on a helper with > elevated privileges to do the heavy lifting of allocating and attaching a tap > device to a bridge. We use a special purpose helper because we don't want > to elevate the privileges of more generic tools like brctl. > But you're essentially allowing any user to send packets through the physical interface. Including, say, nobody (who's just broken in through an unrelated service). > From a user perspective, to use bridged networking with a guest, you simply use: > > qemu -hda linux.img -net bridge -net nic > > And assuming a bridge is defined named qemubr0 and the administrator has setup > permissions accordingly, it will Just Work. My hope is that distributions will > do this work as part of the qemu packaging process such that for most users, > the out-of-the-box experience will also Just Work. > For most distributions, the ootb experience is already much better than running qemu on the command line. I'm not sure who we're optimizing for here, and concerned that we're loosening security for qemu non-users. -- error compiling committee.c: too many arguments to function