qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qem


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
Date: Thu, 05 Nov 2009 07:11:38 -0600
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]