[libvirt] [Patch v2 3/3] apparmor: QEMU bridge helper policy updates

Daniel P. Berrange berrange at redhat.com
Tue Jul 31 09:17:05 UTC 2012


On Mon, Jul 30, 2012 at 06:33:54PM -0600, Jim Fehlig wrote:
> Laine Stump wrote:
> > The way that I think the problem should be solved is this:
> >
> > 1) All of the network-related functionality in the system instance of
> > libvirt that is used by the qemu, lxc, etc. drivers internal to libvirt
> > (including the nwfilter subsystem, and everything in bridge_driver.c)
> > should be in a separate daemon from libvirtd, and made available via RPC
> > with a public API that uses policykit for authorization/authentication,
> > with separate selinux policies from libvirtd; maybe call it
> > "libvirt-networkd".
> >
> > 2) When the system instance of libvirtd is creating a domain, it should
> > call to libvirt-networkd via this API to do things like create a tap
> > device, connect it to a bridge, add nwfilter rules, etc.
> >
> > 3) likewise, when a session (unprivileged) instance of libvirt is
> > creating a domain, it also should call the same APIs, which (after
> > proper authentication/authorization via policykit) will connect it to
> > the privileged libvirt-networkd (or whatever its called) to perform the
> > operation.
> >   
> 
> I wonder if the quantum project [1], which IIUC provides a lot of the
> functionality you describe, could be used as "libvirtd-networkd".

Not as long its its a big mass of python. On the contrary, Quantum could
use libvirt's APIs.


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 :|




More information about the libvir-list mailing list