Open Stack

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 [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
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

-- 

Thanks,

Matt Riedemann