[openstack-dev] Implications of switching to entry points for scheduler filtering/weighing

Doug Hellmann doug.hellmann at dreamhost.com
Thu Jan 3 16:39:09 UTC 2013


On Thu, Jan 3, 2013 at 11:28 AM, Mark McLoughlin <markmc at redhat.com> wrote:

> On Thu, 2013-01-03 at 10:51 -0400, Sandy Walsh wrote:
> >
> > On 01/03/2013 10:27 AM, Monty Taylor wrote:
> > > On 01/03/2013 04:23 AM, Mark McLoughlin wrote:
> > >> On Thu, 2013-01-03 at 12:22 +0000, Mark McLoughlin wrote:
> > >>> Hey,
> > >>>
> > >>> There are some patches proposed for oslo-incubator which adds Nova's
> > >>> filter and weighing infrastructure so that it can be re-used by
> Cinder:
> > >>>
> > >>>   https://blueprints.launchpad.net/oslo/+spec/common-filters
> > >>>
> > >>> One part of this is that we would move to loading filters and
> weighers
> > >>> from entry points. I want to make sure Nova folks are aware of the
> > >>> implications of this before merging it into Oslo.
> > >>
> > >> Bah, I forgot to include the link to the WIP patch for Nova:
> > >>
> > >>   https://review.openstack.org/18718
> > >>
> > >> And if anyone is thinking "didn't Monty have a patch to do this?",
> > >> you're thinking of a patch to switch to using entry points for the
> > >> scheduler driver and host manager:
> > >>
> > >>   https://review.openstack.org/11557
> > >
> > > I, for one, welcome our new filters and weighers overlords.
> >
> > 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.

Doug


>
> Cheers,
> Mark.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130103/c9819bb4/attachment.html>


More information about the OpenStack-dev mailing list