Open Stack

Eric Windisch wrote:
> On Tuesday, June 5, 2012 at 19:18 PM, Joshua Harlow wrote:
> 
>> 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.

Indeed.

> Three options seem to exist:
> [...]
> 
> 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.

This is the path I'm following in Folsom, as part of
https://blueprints.launchpad.net/nova/+spec/folsom-nova-rootwrap.

My original plan was to let a CommandFilter overload its "execute"
method (which usually would just call subprocess.Popen) to execute
Python code instead of the corresponding shell call.

This adds a bit of confusion (from the code it looks like you're just
running a shell command in utils.execute, whereas nova-rootwrap decides,
in that specific case, to run some python code instead). The benefit is
that it keeps backward compatibility with usage of "sudo" instead of
"sudo nova-rootwrap" as the root wrapper (if you just use "sudo" it
would still work, by calling the real command instead of the python code).

Alternatively, we could stop supporting "sudo" as a root_wrapper in Nova
and add support for calling Python functions in utils.execute and
nova-rootwrap (with filters that would filter function parameters).

What implementation suboption would have your preference ? Is
nova-rootwrap now universally used ? Should we prefer compatibility or
absence of confusion ?

> 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.

This is the most elegant, but also the trickiest to secure option.
Attack surface on option #2 is more limited, uses a well-known
escalation mechanism (sudoers), so it's a lot easier to audit.

Regards,

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack