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

[Avi Kivity]

On 11/05/2009 05:50 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
> > > The model you're advocating (privileged process handing over a fd) 
> > > is not as secure because it requires that the management daemon runs 
> > > as a privileged user.
> >
> > Or it can acquire an fd from a privileged helper and pass it on or 
> > conjure it some other way.
>
> So qemu should not be allowed to interact with a privileged helper on 
> it's own?  I can't tell what your objection here is.  Do you want 
> people to just not use qemu directly from the command line?

No, of course not, I use qemu from the command line and would benefit 
from -net bridge.  My badly-conveyed objection is that qemu should not 
take a system management role (and enforce system-wide policies) but 
leave that to system management tools.

Basically, qemu should keep itself to running a single guest and leave 
permissions, multiple guests, system configuration to the management stack.

Of course, -net bridge doesn't prevent the management stack from doing 
management itself (and using -net tap,fd=), but as can be seen from Dan 
Berrange's response, -net bridge might encourage them into laziness; 
then we're on the slippery slope of adding more features to -net bridge 
because libvirt depends on it.  Do you really want to add selinux 
labelling (whatever that is) to qemu?

> > > Management software is really just another user.  We really want 
> > > management software to run unprivileged as much as possible.
> >
> > I'd like to see qemu confined to managing a single guest and not 
> > expand to system management.  We have enough to do without taking 
> > over management systems and security.
> >
> > Bridged network configuration is painful now, but only for a handful 
> > of users (us developers).  For the vast majority it is handled behind 
> > their back by management, which has to deal with a bunch of 
> > privileged stuff anyway (assigned LVM volumes, assigned pci and usb 
> > devices, setting up the bridge, large pages, guest priorities).  Why 
> > are we adding code to benefit so few people, many of whom don't 
> > really use qemu as users?
>
> I strongly disagree with the way you separate users who use management 
> software from people who invoke qemu directly.  libvirt and 
> virt-manager are existence proofs that management software heavily 
> relies on the defaults and mechanisms we establish within qemu. 

So you say, if someone makes a wrong decision, we should fix it by 
making the decision ourselves?

-net bridge will only dig them deeper into qemu defaults.

> We can say all we want about how management software should do things 
> but the best way is to make it easy for them to do the right thing.

Except it's not the right thing, at least not completely.  Creating the 
tap and attaching it to a bridge is just a part of configuring 
networking.  You're making it easy to do that part and impossible to do 
the rest.

Perhaps the same patchset, but to libvirt-devel, would be more useful 
since they can then add any extra features without burdening qemu.

--
error compiling committee.c: too many arguments to function