[openstack-dev] [os-brick][nova][cinder] os-brick/privsep change is done and awaiting your review

Angus Lees gus at inodes.org
Tue Mar 22 22:37:13 UTC 2016


On Sat, 19 Mar 2016 at 06:27 Matt Riedemann <mriedem at linux.vnet.ibm.com>
wrote:

> I stared pretty hard at the nova rootwrap filter change today [1] and
> tried to keep that in my head along with the devstack change and the
> changes to os-brick (which depend on the devstack/cinder/nova changes).
> And with reading the privsep-helper command code in privsep itself.
>
> I realize this is a bridge to fix the tightly couple lockstep upgrade
> issue between cinder and nova, but it would be super helpful, at least
> for me, to chart out how that nova rootwrap filter change fits into the
> bigger picture, like what calls what and how, where are things used, etc.
>
> I see devstack passing on the os-brick change so I'm inclined to almost
> blindly approve to just keep moving, but I'd feel bad about that. Would
> it be possible to flow chart this out somewhere?
>

Sorry for all the confusion Matt.  I obviously explained it poorly in my
gerrit reply to you and I presume also in the parts of the oslo spec that
you've read, so I'll try another explanation here:

privsep fundamentally involves two processes - the regular (nova, whatever)
unprivileged code, and a companion Unix process running with some sort of
elevated privileges (different uid/gid, extra Linux capabilities,
whatever).  These two processes talk to each other over a Unix socket in
the obvious way.

*Conceptually* the companion privileged process is a fork from the
unprivileged process - in that the python environment (oslo.config, etc)
tries to be as similar as possible and writing code that runs in the
privileged process looks just like python defined in the original process
but with a particular decorator.

privsep has two modes of setting up this split-process-with-ipc-channel
arrangement:
- One is to use a true fork(), which follows the traditional Unix daemon
model of starting with full privileges (from init or whatever) and then
dropping privileges later - this avoids sudo, is more secure (imo), and is
a whole lot simpler in the privsep code, but requires a change to the way
OpenStack services are deployed, and a function call at the top of main()
before dropping privileges.
- The second is to invoke sudo or sudo+rootwrap from the unprivileged
process to run the "privsep-helper" command that you see in this change.
This requires no changes to the way OpenStack services are deployed, so is
the method I'm recommending atm.  (We may never actually use the fork()
method tbh given how slowly things change in OpenStack.)  It is completely
inconsequential whether this uses sudo or sudo+rootwrap - it just affects
whether you need to add a line to sudoers or rootwrap filters.  I chose
rootwrap filter here because I thought we had greater precedent for that
type of change.

So hopefully that makes the overall picture clear:  We need this nova
rootwrap filter addition so privsep-helper can use sudo+rootwrap to become
root, so it can switch to the right set of elevated privileges, so we can
run the relevant privsep-decorated privileged functions in that privileged
environment.

I also have a concern in there about how the privsep-helper rootwrap
> command in nova is only using the os-brick context. What happens if
> os-vif and nova need to share common rootwrap commands? At the midcycle
> Jay and Daniel said there weren't any coming up soon, but if that
> happens, how do we handle it?


privsep is able to have different "privileged contexts", which can each run
as different uids and with different Linux capabilities.  In practice each
context has its own privileged process, and if we're using the
sudo(+rootwrap) and privsep-helper method, then each context will want its
own line in sudoers or rootwrap filters.
It is expected that most OpenStack services would only have one or maybe
two different contexts, but nova may end up with a few more because it has
its fingers in so many different pies.  So yes, we'll want another entry
similar to this one for os-vif - presumably os-vif will want CAP_NET_ADMIN,
whereas os-brick wants various storage device-related capabilities.


Again, I'm disappointed the relevant section of the privsep spec failed to
explain the above sufficiently - if this conversation helps clarify it for
you, *please* suggest some better wording for the spec.  It seems
(understandably!) no-one wants to approve even the smallest self-contained
privsep-related change without understanding the entire overall process, so
I feel like I've had the above conversation about 10 times now.  It would
greatly improve everyone's productivity if we can get the spec (or some new
doc) to a place where it can become the place where people learn about
privsep, and they don't have to wait for me to reply with poorly summarised
versions.

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160322/9cc082a5/attachment.html>


More information about the OpenStack-dev mailing list