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

[Avi Kivity]

On 11/06/2009 04:19 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
> > > Instead of doing silly things into qemu, if there is concern about 
> > > this, then it should be fixed in Linux properly.
> >
> > Of course there is concern about it, and you don't have to do 
> > anything silly to qemu to avoid it.  Just not call helpers while it's 
> > running.
>
> This is unacceptable.  We use helpers in multiple places today.  We 
> use a helper to configure a tap device that we've allocated, we use it 
> for the exec: protocol for live migration, etc.

I hope none of these are ever used in production systems.  Taps should 
come pre-configured from management (no need for management to ask qemu 
to run a management helper when management could run that helper more 
easily itself).  exec: migration is also pointless when you can pass and 
fd and do any proxying required.

> Running qemu directly from the command line is absolutely an important 
> use case. 

Where does this requirement come from?

We probably have different ideas of what a desktop user means.  In my 
mind, a desktop user doesn't switch to the monitor and type 'eject', he 
clicks a button with an eject icon and a text caption underneath.  He 
doesn't run qemu-img create -f qcow2 /images/vm1.img, he clicks 'New 
Virtual Machine Wizard' and answers all the tedious questions.  And he 
absolutely doesn't type

  qemu-system-x86_64 -enable-kvm -m 1G -smp 2 -net 
nic,macaddr=aa:00:00:00:00:01 /images/vm1.img -cdrom 
/images/iso/en_us_....blah.iso,

instead he clicks My\ New\ Virtual\ Machine\ \(copy\).qemu on his desktop.

> A desktop user should not need things like libvirt and virt-manager.

virt-mananger is miles ahead of where you're aiming.

I'd like to a proper same-process graphical UI client.  But I don't 
think this list is the place to create it.  I don't think we have either 
the skills or the patience; also there's room for more than one.  We 
should focus on making it easy to write one; that involves exporting the 
display surface in an embeddable non-vnc way and making everything 
controllable via QObjects (perhaps through the monitor, perhaps through 
bindings for scripting languages.

> If it cannot be fixed in the kernel, we'll have to work around it in 
> userspace.  We can introduce our own spawn() function that works by 
> fork()'ing very early and listening on a socketpair.  This will sit 
> reading from the socket waiting for commands to exec.  Using a unix 
> socket, we can pass fds that get inherited which we can't do with 
> system().

Or we can admit to ourselves that qemu is too complex to be directly 
controlled by a user.  It's good to have an easy to use command line for 
developers and power users; I'd welcome -net bridge as one of them.  But 
we shouldn't try to invent access control systems or install suid 
helpers.  Mainstream use needs to involve some management agent which 
does authentication and privileged configuration (it was already 
established that the the hotplug equivalent of -net bridge is racy if 
any configuration is required).

> > > I'd rather not have a program running with elevated privileges when 
> > > it not needed.
> >
> > suid helpers are dangerous whenever they are on disk; daemons are 
> > dangerous only when running.
>
> A suid helper equivalent to a root daemon from a security 
> perspective.  It's just long running vs. transient.

They are not equivalent.  suid helpers are dangerous whenever they are 
on disk; daemons are dangerous only when running.

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.