<br><br><div class="gmail_quote">On Thu, Jan 3, 2013 at 9:50 PM, Huang Zhiteng <span dir="ltr"><<a href="mailto:winston.d@gmail.com" target="_blank">winston.d@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Fri, Jan 4, 2013 at 1:08 AM, Doug Hellmann<br>
<<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>> wrote:<br>
><br>
><br>
> On Thu, Jan 3, 2013 at 11:57 AM, Sandy Walsh <<a href="mailto:sandy.walsh@rackspace.com">sandy.walsh@rackspace.com</a>><br>
> wrote:<br>
>><br>
>><br>
>><br>
>> On 01/03/2013 12:39 PM, Doug Hellmann wrote:<br>
>> ><br>
>> ><br>
>> > On Thu, Jan 3, 2013 at 11:28 AM, Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a><br>
>> > <mailto:<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>>> wrote:<br>
>> ><br>
>> >     On Thu, 2013-01-03 at 10:51 -0400, Sandy Walsh wrote:<br>
>> >     ><br>
>> >     > Yep, having the shared filters/weighers sounds cool.<br>
>> >     ><br>
>> >     > Is there a security concern about using the entry-point mechanism<br>
>> > for<br>
>> >     > allowing untrusted code access to the rich scheduler data (host &<br>
>> >     > request info)?<br>
>> >     ><br>
>> >     > For example, someone installs a sneaky python package on a<br>
>> > scheduler<br>
>> >     > node that has an entry-point that the scheduler uses. We wouldn't<br>
>> > want<br>
>> >     > that to suddenly being included in the filter chain.<br>
>> >     ><br>
>> >     > The old filter driver mechanism, while clunky, was at least<br>
>> >     explicit. Or<br>
>> >     > am I missing something here?<br>
>> ><br>
>> >     Sure, it's very important that unprivileged users can't make the<br>
>> >     scheduler (or any other service) load untrusted code.<br>
>> ><br>
>> >     However, in a sanely configured system, only root or the user which<br>
>> > the<br>
>> >     scheduler is running as can register an entry point. You basically<br>
>> > need<br>
>> >     to be able to install a python egg in the scheduler's python path.<br>
>> ><br>
>> ><br>
>> > If the plugins are enabled explicitly through a config file, it is also<br>
>> > possible to avoid loading extra modules just because they are<br>
>> > discovered. Scanning the list of registered entry points doesn't require<br>
>> > loading their code.<br>
>><br>
>> Thanks Doug, that's what I was looking for. Hopefully that's the default<br>
>> behaviour? It would be pretty easy to trick trick someone to install a<br>
>> "utility" python library.<br>
><br>
><br>
> The code that calls pkg_resources to find the entry points gets back an<br>
> EntryPoint object, which has a load() method to cause the code to be<br>
> imported. Stevedore filters plugins by name now, but after a quick review of<br>
> the code I see that it does so in a way that causes them to be loaded before<br>
> that check function is called [1]. I can fix that, and will open a bug to do<br>
> so.<br>
><br>
> Doug<br>
><br>
> [1]<br>
> <a href="https://github.com/dreamhost/stevedore/blob/master/stevedore/enabled.py#L43" target="_blank">https://github.com/dreamhost/stevedore/blob/master/stevedore/enabled.py#L43</a><br>
><br>
</div></div>Thanks Doug for taking care of this!  Will update Nova/Oslo dependency<br>
list once your fix is merged into stevedore.<br></blockquote><div><br></div><div>Release 0.8 of stevedore should resolve this issue.</div><div><br></div><div>Doug</div><div><br></div></div>