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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
