----- Original Message -----
> On Tue, Nov 22, 2011 at 04:45:56PM -0500, Ayal Baron wrote:
> > 
> > 
> > ----- Original Message -----
> > > Hi guys,
> > > 
> > > I've got MOM up and running as a vdsm thread but I've hit two
> > > small
> > > problems.
> > > I'll bounce them around on the list to see if people have some
> > > ideas.
> > > 
> > > 1.) Libvirt SASL authentication
> > > 
> > > I was able to easily modify MOM to connect to libvirt by
> > > hardcoding
> > > the vdsm
> > > credentials.  Obviously this is not an acceptable long-term
> > > solution.
> > >  What is
> > > the best way to share the vdsm libvirt password with MOM in a way
> > > that does not
> > > compromise security?  Whatever method we choose should not
> > > involve
> > > vdsm-specific
> > > changes to MOM.  For starters I think I will just place the
> > > username
> > > and
> > > password in the mom.conf file.  We could make this file readable
> > > only
> > > by the
> > > vdsm user.  Thoughts?
> > > 
> > > 2.) Permissions
> > > 
> > > The first error I noticed was MOM failing to adjust KSM via
> > > sysfs:
> > > 
> > > 2011-11-22 10:13:48,313 - mom.Controllers.KSM - WARNING - KSM:
> > > Failed
> > > to write
> > > /sys/kernel/mm/ksm/run: Permission denied
> > > 
> > > MOM is used to running as root so that it can adjust these
> > > settings.
> > >  I would
> > > prefer not to complicate the MOM architecture by having a
> > > separate
> > > process that
> > > receives instructions from the main MOM thread and then applies
> > > the
> > > requested
> > > changes as root.
> > > 
> > > Another solution would be to allow MOM to run as a completely
> > > separate daemon
> > > (as it has been originally doing).  In this scenario, vdsm would
> > > reconfigure MOM
> > > by replacing the default configuration file and policy.  vdsm
> > > could
> > > then
> > > interact with the running momd via the existing xmlrpc interface.
> > > 
> > > Thoughts on these issues?
> > 
> > In continuation to our discussion from yesterday, both issues would
> > be
> > non-issues if we were to fully integrate MOM into vdsm.  However, I
> > get the
> > feeling we might be mixing things here.  Correct me if I'm wrong
> > but the
> > general architecture is: different data collectors -> MOM policy
> > engine ->
> > actions to perform
> 
> Yes, you have the architecture correctly.
> 
> > Seeing as vdsm already today monitors and collects info from the
> > guests, it
> > should just be defined as a data collector and solve that side of
> > the issue.
> 
> Yes, this should be just fine.
> 
> > Then we have the issue of performing the actions.  Currently mom
> > executes
> > these directly, right? if so, we could split that so that mom's
> > output is a
> > series of actions to perform which vdsm could then execute (if this
> > sounds
> > familiar it is because this is how pacemaker works and I think they
> > got it
> > right).
> 
> Yes, MOM currently executes the actions directly.  Given that the
> goal of
> supervdsm is to provide a limited set of very specific actions, I am
> wondering
> how extensible it will be for flexible management tasks.  I guess I
> will try it
> out with KSM first and see how it would work.

I don't see any other viable way of doing this securely.  The policy basically 
determines what actions have to be run.  MOM is fed this policy by unprivileged 
users. If mom were to run arbitrary commands using root user based on a policy 
given to it by a non root user, that would be a security breach. Unless I'm 
missing something, the alternative (assuming again mom is root) is to mandate 
having a static policy persistent on disk, but it would still need to get there 
securely and again poses a problem.
I think having to expose specific (high level) tuning operations in the 
privileged process makes you think about the things you are doing and whether 
there is a safer way for doing the same thing.

> 
> > This means that in the vdsm-less scenario we would be missing an
> > orchestrator,
> > but that could easily be adapted.
> 
> In the vdsm-less scenario, we'd just use the existing sets of
> Collectors and
> Controllers.
> 
> > Then whether the policy engine runs as a daemon or is just spawned
> > internally
> > is up to the application calling it.
> 
> Yes, this is how I have changed MOM to work now.  The RPM installs a
> system-wide
> daemon that can be started.  Otherwise, an application can load the
> module,
> configure it, and run it at will.
> 
> --
> Adam Litke <a...@us.ibm.com>
> IBM Linux Technology Center
> 
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to