<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 30, 2013 at 8:55 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">Joe Gordon wrote:<br>
> Going forward I think we should support two approaches:<br>
><br>
> 1) some faster mostly python based (because we are a python project)<br>
> rootwrap solution, there are many good ideas proposed above.   Although<br>
> Robert Collins comments have yet to be addressed.<br>
<br>
</div>About Robert's arguments: most filters operate on command arguments<br>
without checking state, so they don't introduce a TOCTOU race. Some<br>
advanced filters indeed use current state of the system in their checks<br>
so they introduce a TOCTOU race but those are not thought to be<br>
exploitable. For example KillFilter checks the PID target before it<br>
kills it, but since you don't control PID allocation you can't exploit<br>
that race to gain anything.<br>
<div class="im"><br>
> 2) Also support just using sudo.<br>
> Assuming any sort of rootwrap solution we propose will incur a non-zero<br>
> overhead, I can imagine some users wanting to sacrifice some security<br>
> for performance.   For example if they run a private cloud where the<br>
> tenants are mostly trusted.<br>
<br>
</div>Now that's interesting, because we actually don't support running "sudo"<br>
as the root wrapper anymore (since Folsom/Grizzly). We removed the<br>
"root_helper" parameter (in Nova and Cinder) and use "rootwrap_config"<br>
instead.<br>
<br>
You can still bypass rootwrap completely by running the component as the<br>
root user instead of the unprivileged (nova) user, but that's about it.<br>
Is that really a use case we want to support ?<br>
<br>
Note that if we add the ability to run python snippets of code in<br>
rootwrap, we'll definitely lose the ability to run outside rootwrap. So<br>
there seems to be a trade-off here:<br>
<br>
I thought we could move functions like<br>
linux_net.initialize_gateway_device to a Python snippet library that<br>
rootwrap would run in one go (using some artificial construct like<br>
"nova-rootwrap /etc/nova/rootwrap.conf py initialize_gateway_device<br>
parameters...") but then we'd lose the ability to run as the root user<br>
and to bypass rootwrap completely (since sudo py<br>
initialize_gateway_device wouldn't do you any good)... or maybe we can<br>
come up with a construct that would still work when called using basic<br>
sudo ?<br></blockquote><div><br></div><div>So whatever solution we go with, I think we need something for Havana.  As even with removing pkg_resources from the binaries (<span style="color:rgb(51,51,51);font-family:'Ubuntu Mono',monospace;font-size:12px;line-height:18px"> </span><a rel="nofollow" href="https://review.openstack.org/#/c/38000/" style="color:rgb(51,102,204);font-family:'Ubuntu Mono',monospace;font-size:12px;line-height:18px">https://review.openstack.org/#/c/38000/</a> ) rootwrap is still too slow to boot 50 instances at once (see <a href="https://bugs.launchpad.net/oslo/+bug/1199433">https://bugs.launchpad.net/oslo/+bug/1199433</a> for details).  I tried swapping out rootwrap for sudo and that made the issue go away.    So I think we should go back to supporting just using sudo instead of rootwrap, and make sure any future solutions support a sudo only option as well.  But I am open to other ideas, I just think we need to implement something for Havana.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
</font></span><div class=""><div class="h5"><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></div></div>