From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N627u-0004fm-NU for qemu-devel@nongnu.org; Thu, 05 Nov 2009 08:11:46 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N627p-0004ea-UF for qemu-devel@nongnu.org; Thu, 05 Nov 2009 08:11:46 -0500 Received: from [199.232.76.173] (port=40658 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N627p-0004eT-SM for qemu-devel@nongnu.org; Thu, 05 Nov 2009 08:11:41 -0500 Received: from qw-out-1920.google.com ([74.125.92.150]:34029) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N627p-0001QY-Ky for qemu-devel@nongnu.org; Thu, 05 Nov 2009 08:11:41 -0500 Received: by qw-out-1920.google.com with SMTP id 5so1571408qwc.4 for ; Thu, 05 Nov 2009 05:11:41 -0800 (PST) Message-ID: <4AF2CF0A.1000604@codemonkey.ws> Date: Thu, 05 Nov 2009 07:11:38 -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> <20091105041236.GA4981@shareable.org> In-Reply-To: <20091105041236.GA4981@shareable.org> 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: Jamie Lokier Cc: Mark McLoughlin , Anthony Liguori , Arnd Bergmann , Juan Quintela , Dustin Kirkland , qemu-devel@nongnu.org, Michael Tsirkin Jamie Lokier wrote: > Anthony Liguori wrote: > >> 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... > I mention this in one of my patches. The problem with persistent tun devices is that every time a user needs to create a guest, an adminstrator action is needed. That doesn't extend well to a system that Just Works. >> 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. > The problem with this is that the helper runs with increased capabilities but as a lesser user. Various networking commands don't necessarily behave well when run like this. But more importantly, you would have to run the helper with inheritable privileges which is a bigger security risk than what we do at the moment. There's only one way to add a device to a bridge so I'm not sure it's really necessary either. > 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? > The helper does return an fd. The internal implementation is pretty much -net tap,fd=N. You can point it to a different helper if you'd like by saying -net bridge,helper=my-helper. That said, the helper has to have greater privileges than qemu itself so it's something that needs to be very carefully implemented/designed. I don't think it's something you want normal users mucking around with. Regards, Anthony Liguori