On Tue, Nov 29, 2011 at 01:11:18PM -0600, Adam Litke wrote:
> On Tue, Nov 29, 2011 at 05:44:23PM +0000, Daniel P. Berrange wrote:
> > On Tue, Nov 29, 2011 at 11:18:42AM -0600, Adam Litke wrote:
> > > 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.
> > FWIW, connecitng to qemu:///system does not require root. Traditionally VDSM
> > configures SASL, so all that would be required is to create a SASL username
> > and password for Momd. Alternatively if the default policykit auth is in
> > effect for libvirtd, the mom RPM could simply drop a policy file into the
> > right location to allow processes under the 'momd' UNIX user to connect.
> Yep. I've already got a patch for MOM to use SASL for libvirt connections.
> > I don't have a clear answer for the KSM thing & other tunables momd might
> > need to deal with. There is perhaps a gap here for a system tunable daemon
> > to provide an RPC service over DBus, which momd then uses to change sysfs
> > tunables. Or something...
> At the end of the day We have to let something be root, why not MOMd? It is
> already slim and narrowly focused on stats collection and response.
> yet another daemon just adds complexity and requires us to change more
> components each time we want to do something. A "generic" tunable daemon
> likely not be part of oVirt and would not adhere to our release cadence; thus
> decreasing our ability to add new functionality.
I guess my desire is that the bit that runs as root should do as little as
possible, ideally simply be a conduit for reading / writing a well defined
set of resources. Momd has pluggable policy which can, to some degree, be
considered untrusted compared to the rest of Momd. So if it were possible
to have the actual policy processing part of momd running separately from
the bit of momd that actually interfaces to the kernel, that could be a
useful security barrier.
That all said, I think that confining momd with an effective SELinux
security policy is more important, than running as non-root. So if we
had to choose, I'd focus on the SELinux policy side of things.
|: 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