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.
