On Tue, Nov 29, 2011 at 04:50:19PM +0000, Daniel P. Berrange wrote:
> 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 ?
Very good questions -- thanks for raising them. I've listed it as a con because
others have raised it as a concern. MOM runs as root for a few reasons: to
connect to the qemu:///system libvirt URI, to connect to guest agent sockets,
and (most difficult to mitigate) to reconfigure KSM via sysfs. As MOMs
Controllers expand in functionality the need to root access will increase.
The way vdsm works around this problem is that it spawns a 'supervdsm' process
that has root privileges. To make MOM work from within a VDSM thread, all
root-requiring operations must be routed through the supervdsm API. In my
opinion, this is far from optimal and causes the MOM Controller API to become
unnecessarily layered. It also peppers the vdsm codebase with bits of
privileged code. Over time, this will become increasingly difficult to manage.
> 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.
I agree with this...
> 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".
... and this. Additionally, when running standalone, MOM can focus on being a
system tuning mechanism. Some tuning and stats collection will necessarily go
through the VDSM API but some will not need to. I think Plan A represents the
UNIX model of orchestrating small components together to perform complex tasks.
Adam Litke <a...@us.ibm.com>
IBM Linux Technology Center
vdsm-devel mailing list