Open Stack

On Thu, Jan 3, 2013 at 9:50 PM, Huang Zhiteng <winston.d at gmail.com> wrote:

> On Fri, Jan 4, 2013 at 1:08 AM, Doug Hellmann
> <doug.hellmann at dreamhost.com> wrote:
> >
> >
> > On Thu, Jan 3, 2013 at 11:57 AM, Sandy Walsh <sandy.walsh at rackspace.com>
> > wrote:
> >>
> >>
> >>
> >> 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.
> >
> >
> > The code that calls pkg_resources to find the entry points gets back an
> > EntryPoint object, which has a load() method to cause the code to be
> > imported. Stevedore filters plugins by name now, but after a quick
> review of
> > the code I see that it does so in a way that causes them to be loaded
> before
> > that check function is called [1]. I can fix that, and will open a bug
> to do
> > so.
> >
> > Doug
> >
> > [1]
> >
> https://github.com/dreamhost/stevedore/blob/master/stevedore/enabled.py#L43
> >
> Thanks Doug for taking care of this!  Will update Nova/Oslo dependency
> list once your fix is merged into stevedore.
>

Release 0.8 of stevedore should resolve this issue.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130104/3a1f7ce7/attachment.html>