From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N5TjX-00023C-A9 for qemu-devel@nongnu.org; Tue, 03 Nov 2009 19:28:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N5TjS-0001y4-G1 for qemu-devel@nongnu.org; Tue, 03 Nov 2009 19:28:18 -0500 Received: from [199.232.76.173] (port=55915 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N5TjS-0001xt-43 for qemu-devel@nongnu.org; Tue, 03 Nov 2009 19:28:14 -0500 Received: from e5.ny.us.ibm.com ([32.97.182.145]:49735) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N5TjR-0006Z7-KL for qemu-devel@nongnu.org; Tue, 03 Nov 2009 19:28:13 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e5.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nA40HsRZ004234 for ; Tue, 3 Nov 2009 19:17:54 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nA40S7NM101280 for ; Tue, 3 Nov 2009 19:28:09 -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 nA3ERDR1014045 for ; Tue, 3 Nov 2009 09:27:14 -0500 From: Anthony Liguori Date: Tue, 3 Nov 2009 18:28:01 -0600 Message-Id: <1257294485-27015-1-git-send-email-aliguori@us.ibm.com> Subject: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Mark McLoughlin , Michael Tsirkin , Arnd Bergmann , Juan Quintela , Dustin Kirkland 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. 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. 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. >>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. More details are included in individual patches. I broke up the helper into a series of patches to improve reviewabilty.