Il 25/03/2013 15:25, Paolo Bonzini ha scritto:
The <interface type='bridge'> is working mostly because
of a bad design
decision in Linux. Ideally, QEMU would run with an empty capability
bounding set and would not be able to do any privileged operation
(not even by running a helper program). This is not the case because
dropping capabilities from the bounding set requires a capability of its
own, CAP_SETPCAP; thus QEMU does *not* run with an empty bounding set if
invoked via qemu:///session.
This series lets libvirtd invoke the privileged helper program on its own,
which is a cleaner design that would work even if the above Linux bug
was not there. Also, this adds a <target dev='tap0'/> element to the
XML of an active domain using <interface type='bridge'>.
libvirt now needs to know the path to the helper (patch
3), and must not set permitted/effective capabilities on children when
running unprivileged (patches 1/2). Apart from this, the recvfd and
virCommand APIs make the task almost trivial.
Paolo Bonzini (5):
util: simplify virSetUIDGIDWithCaps
util: allow using virCommandAllowCap with setuid helpers
qemu_conf: add new configuration key bridge_helper
virnetdevtap: add virNetDevTapGetName
qemu: launch bridge helper from libvirtd
src/libvirt_private.syms | 1 +
src/qemu/libvirtd_qemu.aug | 1 +
src/qemu/qemu.conf | 8 +++
src/qemu/qemu_command.c | 133 +++++++++++++++++++++++++++----------
src/qemu/qemu_command.h | 1 -
src/qemu/qemu_conf.c | 3 +
src/qemu/qemu_conf.h | 1 +
src/qemu/qemu_hotplug.c | 25 +++----
src/qemu/test_libvirtd_qemu.aug.in | 1 +
src/util/virnetdevtap.c | 33 +++++++++
src/util/virnetdevtap.h | 3 +
src/util/virutil.c | 36 +++++++---
12 files changed, 183 insertions(+), 63 deletions(-)
Ping?
Paolo