[openstack-dev] [os-brick][nova][cinder] os-brick/privsep change is done and awaiting your review
mriedem at linux.vnet.ibm.com
Wed Mar 23 21:41:24 UTC 2016
On 3/22/2016 5:37 PM, Angus Lees wrote:
> On Sat, 19 Mar 2016 at 06:27 Matt Riedemann <mriedem at linux.vnet.ibm.com
> <mailto:mriedem at linux.vnet.ibm.com>> wrote:
> I stared pretty hard at the nova rootwrap filter change today  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,
> 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
> - 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
> 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
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
Thanks Angus, this is really helpful, and thank you for being patient.
I've approved the nova rootwrap filter patch. I see there are some
issues coming up with the os-brick patch so that might take a bit longer
(the dependency chain is growing), but those seem straight-forward at least.
As for the spec, I read through some of it but I think I really needed
the actual series of changes under review now to see how the pieces fit
More information about the OpenStack-dev