Open Stack

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.

-- 
Regards
Huang Zhiteng