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. Introducing yet another daemon just adds complexity and requires us to change more components each time we want to do something. A "generic" tunable daemon would likely not be part of oVirt and would not adhere to our release cadence; thus decreasing our ability to add new functionality. > > 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 :| > -- Adam Litke <a...@us.ibm.com> IBM Linux Technology Center _______________________________________________ vdsm-devel mailing list firstname.lastname@example.org https://fedorahosted.org/mailman/listinfo/vdsm-devel