From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N5tiI-0003OZ-CF for qemu-devel@nongnu.org; Wed, 04 Nov 2009 23:12:46 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N5tiD-0003JE-QY for qemu-devel@nongnu.org; Wed, 04 Nov 2009 23:12:45 -0500 Received: from [199.232.76.173] (port=54766 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N5tiD-0003J7-Nt for qemu-devel@nongnu.org; Wed, 04 Nov 2009 23:12:41 -0500 Received: from mail2.shareable.org ([80.68.89.115]:49247) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N5tiD-0006o3-Dj for qemu-devel@nongnu.org; Wed, 04 Nov 2009 23:12:41 -0500 Date: Thu, 5 Nov 2009 04:12:36 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu Message-ID: <20091105041236.GA4981@shareable.org> References: <1257294485-27015-1-git-send-email-aliguori@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1257294485-27015-1-git-send-email-aliguori@us.ibm.com> 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 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. > > 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. I've been using KVM for a year or so with bridged networking, without needing to run it as root. So there's obviously been some bad advice floating around :-) What I do is have tun interfaces owned by the user... > 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. I think it's a great idea. It would be even more useful if the "bridge setup" and "bridge teardown" helper commands could be specified as qemu options, and eventually as config file entries, in the same way as script= and downscript= are already. That way it would be useful for all sorts of network configurations where a user-allocatable tap+bridge interface is needed. You can do it now by wrapping _around_ qemu using the -net tap,fd=N option, but calling a helper to get assigned a tap interface is much neater. By the way, would it make sense for the helper to return an open file descriptor rather than an interface name, just like -net tap,fd=N uses? Or does qemu need to access the interface by name anyway? I notice that if we eventually teach the kernel to have unnamed bridges (just attach interfaces to each other), only the helper commands will need changing to use it :-) -- Jamie