Open Stack

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.