On Thu, Oct 06, 2011 at 02:38:56PM -0400, Corey Bryant wrote:
On 10/06/2011 02:04 PM, Anthony Liguori wrote:
On 10/06/2011 11:41 AM, Daniel P. Berrange wrote:
On Thu, Oct 06, 2011 at 11:38:25AM -0400, Richa Marwaha wrote:
This patch adds a helper that can be used to create a tap device
attached to
a bridge device. Since this helper is minimal in what it does, it can be
given CAP_NET_ADMIN which allows qemu to avoid running as root while
still
satisfying the majority of what users tend to want to do with tap
devices.
The way this all works is that qemu launches this helper passing a
bridge
name and the name of an inherited file descriptor. The descriptor is one
end of a socketpair() of domain sockets. This domain socket is used to
transmit a file descriptor of the opened tap device from the helper
to qemu.
The helper can then exit and let qemu use the tap device.
When QEMU is run by libvirt, we generally like to use capng to
remove the ability for QEMU to run setuid programs at all. So
obviously it will struggle to run the qemu-bridge-helper binary
in such a scenario.
With the way you transmit the TAP device FD back to the caller,
it looks like libvirt itself could execute the qemu-bridge-helper
receiving the FD, and then pass the FD onto QEMU using the
traditional tap,fd=XX syntax.
Exactly. This would allow tap-based networking using libvirt session://
URIs.
I'll take note of this. It seems like it would be a nice future
addition to libvirt.
A slight tangent, but a point on DAC isolation. The helper enables
DAC isolation for qemu:///session but we still need some work in
libvirt to provide DAC isolation for qemu:///system. This could be
done by allowing management applications to specify custom
user/group IDs when creating guests rather than hard coding the IDs
in the configuration file.
Yes, this is a item on our todo list for libvirt. There are a couple of
work items involved
- Extend the XML to allow multiple<seclabel> elements, one per
security driver in use.
- Add a new API to allow fetching of live seclabel data per
security driver
- Extend the current DAC security driver to automatically allocate
UIDs from an admin defined range, and/or pull them from the XML
provided by app.
Tecnically we could do item 3, without doing items 1/2, but that would
neccessitate *not* using the sVirt security driver. I don't think that's
too useful, so items 1/2 let us use both the sVirt& enhanced DAC driver
at the same time.