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. 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... > 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. Yeah, I think that is really sub-optimal from the security POV, because both VDSM & supervdsm cover a very broad range of functionality so it will be hard to offer a meaningful level of security policy acround them, as compared to a dedicated Momd daemon. > > 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 > -- |: 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 vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
