On Tue, Nov 29, 2011 at 10:29:41AM -0600, Adam Litke wrote:
> After discussing MOM / VDSM integration at length, two different strategies 
> have
> emerged.  I will call them Plan A and Plan B:
> Plan A: MOM integration at the OS/Packaging level
> Plan B: MOM integration as a new VDSM thread
> This RFC is about Plan A.  I will start another thread to discuss Plan B once 
> I
> have properly prototyped the idea in code.
> Integration VDSM and MOM at the OS level is by far the simpler and least
> intrusive option.  As you can see from the included patch, the changes to vdsm
> are very limited.  In this model, VDSM interacts with MOM in the same way as 
> it
> uses libvirt.  Upon installation, VDSM installs its own MOM configuration file
> and restarts the MOM daemon (which continues to exist as an independent
> system-level daemon).  Once restarted, MOM will load its policy from the VDSM
> configuration directory.
> Pros:
> - Simple and unobtrusive to either MOM or VDSM
> - Clean API with no duplication or layering
> - Maintain flexibility to tighten integration in the future
> Cons:
> - Momd runs as root (like supervdsm)
> - If MOM will consume VDSM APIs, it must use the slower xmlrpc interface

I curious about the 'runs as root' bit. By listing it as a Con here,
you imply that if it were a VDSM thread, it could run as non-root ?
What is it that Momd has todo that requires root when run outside
of VDSM, yet is not a problem when inside VDSM ? IOW can it not be
made to run as 'momd' user/group when standalone ?

IMHO, having a Momd that is a separate process from VDSM is pretty
desirable from the security POV. It is much more practical to write
a strict SELinux security policy for a fairly self-contained set of
functionality like Momd, than to write a policy for the very broad
functionality of VDSM as a whole.

Also, if Momd is separate, and talking to libvirt at all, then we
will also be able to take advantage of libvirt's future RBAC
controls, to strictly limit what changes Momd can do down to the
fine level of individual guests or groups of guests. eg you'll be
able to write SELinux policy that allows a process of type  'momd_t'
to only perform libvirt operations X & Y, against guests labelled
"svirt_BLAH_t" while allowing operations X, Y & Z against guest
labelled with "svirt_FOO_t".

|: 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 :|
vdsm-devel mailing list

Reply via email to