[openstack-dev] Implications of switching to entry points for scheduler filtering/weighing
sandy.walsh at rackspace.com
Thu Jan 3 16:57:02 UTC 2013
On 01/03/2013 12:39 PM, Doug Hellmann wrote:
> On Thu, Jan 3, 2013 at 11:28 AM, Mark McLoughlin <markmc at redhat.com
> <mailto:markmc at redhat.com>> wrote:
> On Thu, 2013-01-03 at 10:51 -0400, Sandy Walsh wrote:
> > Yep, having the shared filters/weighers sounds cool.
> > Is there a security concern about using the entry-point mechanism for
> > allowing untrusted code access to the rich scheduler data (host &
> > request info)?
> > For example, someone installs a sneaky python package on a scheduler
> > node that has an entry-point that the scheduler uses. We wouldn't want
> > that to suddenly being included in the filter chain.
> > The old filter driver mechanism, while clunky, was at least
> explicit. Or
> > am I missing something here?
> Sure, it's very important that unprivileged users can't make the
> scheduler (or any other service) load untrusted code.
> However, in a sanely configured system, only root or the user which the
> scheduler is running as can register an entry point. You basically need
> to be able to install a python egg in the scheduler's python path.
> If the plugins are enabled explicitly through a config file, it is also
> possible to avoid loading extra modules just because they are
> discovered. Scanning the list of registered entry points doesn't require
> loading their code.
Thanks Doug, that's what I was looking for. Hopefully that's the default
behaviour? It would be pretty easy to trick trick someone to install a
"utility" python library.
More information about the OpenStack-dev