[Top][All Lists]

[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: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
Date: Sat, 07 Nov 2009 11:14:22 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4

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 

reply via email to

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