From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N63r7-0001Yv-Jn
	for qemu-devel@nongnu.org; Thu, 05 Nov 2009 10:02:33 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N63r2-0001VT-Ug
	for qemu-devel@nongnu.org; Thu, 05 Nov 2009 10:02:33 -0500
Received: from [199.232.76.173] (port=53238 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N63r2-0001VO-QC
	for qemu-devel@nongnu.org; Thu, 05 Nov 2009 10:02:28 -0500
Received: from mx1.redhat.com ([209.132.183.28]:31299)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <markmc@redhat.com>) id 1N63r2-00036J-2V
	for qemu-devel@nongnu.org; Thu, 05 Nov 2009 10:02:28 -0500
From: Mark McLoughlin <markmc@redhat.com>
In-Reply-To: <1257294485-27015-1-git-send-email-aliguori@us.ibm.com>
References: <1257294485-27015-1-git-send-email-aliguori@us.ibm.com>
Content-Type: text/plain
Date: Thu, 05 Nov 2009 10:00:05 -0500
Message-Id: <1257433205.2885.25.camel@blaa>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 0/4] net-bridge: rootless bridge support
	for qemu
Reply-To: Mark McLoughlin <markmc@redhat.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Juan Quintela <quintela@redhat.com>, Michael Tsirkin <mst@redhat.com>, Arnd Bergmann <arndbergmann@googlemail.com>, qemu-devel@nongnu.org, Dustin Kirkland <kirkland@canonical.com>

On Tue, 2009-11-03 at 18:28 -0600, Anthony Liguori wrote:
> 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.

Just had a quick look through so far, but I like it.

I think it would make sense to move Fedora and libvirt to using this,
even for the system libvirtd.

Agree with danpb that we should hook in PolicyKit for the authorization
checking. It'd be nice to setup the PolicyKit auth on a per-bridge
basis, but we could try and figure that out later. A global auth would
be enough to begin with, falling back to the ACL files.

Also, I think the vnet_hdr and sndbuf arguments are valid for -net
bridge too

Cheers,
Mark.