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(-) -- 1.8.1.4 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list