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. 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.
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.
Regards, Daniel