Open Stack

Interesting, darn, that sorta makes it harder than it seems like it should be.

Is there any pattern that we can follow for this that other programs use, do most other programs shell out as root, and expect there command sets to be restricted? Do other similar programs just assume that they are running as a user that won't need to be restricted? Java seems like it would have the same issue, but of course its threaded, I there any similar concept there of temporarily escalating privileges for a thread, performing some action, then reducing privileges? I wonder if eventlet could support something like this (or be modified to?). Anyone else know other ways of doing this that might be useful? The suggestions that involve RPC being one way.

On 6/5/12 5:35 PM, "Eric Windisch" <eric at cloudscaling.com> wrote:





On Tuesday, June 5, 2012 at 19:18 PM, Joshua Harlow wrote:


Re: [Openstack] Question on nova disk injection... Why couldn't nova just escalate pythons privileges to the super user when writing a file (thus allowing it to use python file writing functions and such).

Because we use Eventlet. os.setuid applies to the entire process. Coroutine switching during this would be dangerous.

Three options seem to exist:

1. We can fork, but then we'll need use IPC, which in our case would be implemented via the RPC abstraction.  We would need to make changes to services.py and/or the binaries and possibly the RPC abstraction itself.  This would work well with ZeroMQ as it would be actual IPC, but the brokered RPC solutions would be less efficient. Overall, this reeks of complexity and danger, but the end result should be a clear net positive.

2. One less elegant, but easy, solution might just be to extend the rootwrap functionality. Have it support calling commands on the system *and* executing trusted Python methods with trusted arguments.  We'd still be shelling out to rootwrap, but rootwrap could internally provide 'mkdir' and 'chmod' style commands around the os stdlib, rather than shelling out a second time, as it does currently.

3. rootwrap itself could actually be implemented as a Nova service, if we could trust the RPC mechanism direct access to the rootwrap methods -- which we is not all too safe, currently. This would effectively be a mix of options 1/2.

I'm inclined to suggest option #2 as it is a relatively simple improvement that would give us short-term gains without much friction. This wouldn't exclude the other options from being worked on and seems to be a requirement for #3, anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120605/aa79578a/attachment.html>