[openstack-dev] [os-brick][nova][cinder] os-brick/privsep change is done and awaiting your review
gus at inodes.org
Wed Feb 24 03:51:08 UTC 2016
Most of the various required changes have flushed out by now, and this
change now passes the dsvm-full integration tests(*).
(*) well, the experimental job anyway. It still relies on a
merged-but-not-yet-released change in oslo.privsep so gate + 3rd party
won't pass until that happens.
This change replaces os-brick's use of rootwrap with a quick+dirty
privsep-based drop-in replacement. Privsep doesn't actually provide much
security isolation when used in this way, but it *does* now run commands
with CAP_SYS_ADMIN (still uid=0/gid=0) rather than full root superpowers.
The big win from a practical point of view is that it also means os-brick's
rootwrap filters file is essentially deleted and no longer has to be
manually merged with downstream projects.
Code changes required in nova/cinder:
There is one change each to nova+cinder to add the relevant privsep-helper
command to rootwrap filters, and a devstack change to add a
nova.conf/cinder.conf setting. That's it - this is otherwise a
backwards/forwards compatible change for nova+cinder.
Deployment changes required in nova/cinder:
A new "privsep_rootwrap.helper_command" needs to be defined in
nova/cinder.conf (default is something sensible using sudo), and rootwrap
filters or sudoers updated depending on the exact command chosen. Be aware
that any commands will now be run with CAP_SYS_ADMIN (only), and if that's
insufficient for your hardware/drivers it can be tweaked with other
The end-result is still just running the same commands as before, via a
different path - so there's not a lot of adventurousness here. The big
behavioural change is CAP_SYS_ADMIN, and (as highlighted above) it's
conceivable that the driver for some exotic os-brick/cinder hardware out
there wants something more than that.
- global-requirements change needed (for os-brick) once the latest
oslo.privsep release is made
- cinder/nova/devstack changes need to be merged
- after the above, the os-brick gate integration jobs will be able to pass,
and it can be merged
- If we want to *force* the new version of os-brick, we then need an
appropriate global-requirements os-brick bump
- Documentation, release notes, etc
I'll continue chewing through those remaining work items, but essentially
this is now in your combined hands to prioritise for mitaka as you deem
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev