On 3/22/2016 5:37 PM, Angus Lees wrote:
On Sat, 19 Mar 2016 at 06:27 Matt Riedemann <mrie...@linux.vnet.ibm.com <mailto:mrie...@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-requ...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
