<br><br><div class="gmail_quote">On Thu, Jan 3, 2013 at 11:28 AM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.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 Thu, 2013-01-03 at 10:51 -0400, Sandy Walsh wrote:<br>
><br>
> On 01/03/2013 10:27 AM, Monty Taylor wrote:<br>
> > On 01/03/2013 04:23 AM, Mark McLoughlin wrote:<br>
> >> On Thu, 2013-01-03 at 12:22 +0000, Mark McLoughlin wrote:<br>
> >>> Hey,<br>
> >>><br>
> >>> There are some patches proposed for oslo-incubator which adds Nova's<br>
> >>> filter and weighing infrastructure so that it can be re-used by Cinder:<br>
> >>><br>
> >>>   <a href="https://blueprints.launchpad.net/oslo/+spec/common-filters" target="_blank">https://blueprints.launchpad.net/oslo/+spec/common-filters</a><br>
> >>><br>
> >>> One part of this is that we would move to loading filters and weighers<br>
> >>> from entry points. I want to make sure Nova folks are aware of the<br>
> >>> implications of this before merging it into Oslo.<br>
> >><br>
> >> Bah, I forgot to include the link to the WIP patch for Nova:<br>
> >><br>
> >>   <a href="https://review.openstack.org/18718" target="_blank">https://review.openstack.org/18718</a><br>
> >><br>
> >> And if anyone is thinking "didn't Monty have a patch to do this?",<br>
> >> you're thinking of a patch to switch to using entry points for the<br>
> >> scheduler driver and host manager:<br>
> >><br>
> >>   <a href="https://review.openstack.org/11557" target="_blank">https://review.openstack.org/11557</a><br>
> ><br>
> > I, for one, welcome our new filters and weighers overlords.<br>
><br>
> Yep, having the shared filters/weighers sounds cool.<br>
><br>
> Is there a security concern about using the entry-point mechanism 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 scheduler<br>
> node that has an entry-point that the scheduler uses. We wouldn't want<br>
> that to suddenly being included in the filter chain.<br>
><br>
> The old filter driver mechanism, while clunky, was at least explicit. Or<br>
> am I missing something here?<br>
<br>
</div></div>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 the<br>
scheduler is running as can register an entry point. You basically need<br>
to be able to install a python egg in the scheduler's python path.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Mark.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br>