Open Stack

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.

Cheers,
Mark.