From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48830) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiUxw-0003c9-Bh for qemu-devel@nongnu.org; Wed, 04 Jan 2012 12:49:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiUxv-0003nS-EJ for qemu-devel@nongnu.org; Wed, 04 Jan 2012 12:49:32 -0500 Received: from lo.gmane.org ([80.91.229.12]:58664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiUxv-0003nO-4K for qemu-devel@nongnu.org; Wed, 04 Jan 2012 12:49:31 -0500 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RiUxu-0004a7-CL for qemu-devel@nongnu.org; Wed, 04 Jan 2012 18:49:30 +0100 Received: from barriere.frankfurter-softwarefabrik.de ([217.11.197.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Jan 2012 18:49:30 +0100 Received: from lvml by barriere.frankfurter-softwarefabrik.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Jan 2012 18:49:30 +0100 From: Lutz Vieweg Date: Wed, 04 Jan 2012 18:49:15 +0100 Message-ID: References: <1325697541-2535-1-git-send-email-coreyb@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <1325697541-2535-1-git-send-email-coreyb@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH v7 0/4] -net bridge: rootless bridge support for qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 01/04/2012 06:18 PM, Corey Bryant wrote: > With qemu it is possible to run a guest from an unprivileged user but if > we wanted to communicate with the outside world we had to switch > to root. > > We address this problem by introducing a new network backend and a new > network option for -net tap. I appreciate the effort you've invested to implement this work-around. But I wonder if there isn't a much simpler, and straight-forward method: tap devices, theoretically, already have a "group" assigned to them (as well as a "user"). Currently it seems, though, that the "group" is basically ignored and has no actual influence on who may access a tap device and how. (If "tunctl -p -u username -g groupname -t tapX" was used to create a tap device, the "username" can access it, but not members of "groupname" - for no obvious reasons.) If that was changed, and the "group" was actually honored, the problem would collapse into root needing to create at boot time a useful amount of tap devices attached to whatever bridge appropriate, and assigning the group such that users who should be entitled to use those devices are members of those groups. Then qemu (started as a user) would just need to iterate through the available tap-devices to find one that is unused (if not specified by name) and belongs a group the user is member of. Isn't that much more the "unix"-way, not requiring additional ACLs, not requiring any additional tools being run, not requiring any exploit-prone suid executables? Regards, Lutz Vieweg