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. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
