[openstack-dev] [cinder] [nova] os-brick privsep failures and an upgrade strategy?
gus at inodes.org
Tue Jun 14 22:11:32 UTC 2016
On Tue, 14 Jun 2016 at 23:04 Daniel P. Berrange <berrange at redhat.com> wrote:
> On Tue, Jun 14, 2016 at 07:49:54AM -0400, Sean Dague wrote:
Urgh, thanks for the in-depth analysis :/
> The crux of the problem is that os-brick 1.4 and privsep can't be used
> > without a config file change during the upgrade. Which violates our
> > policy, because it breaks rolling upgrades.
> os-vif support is going to face exactly the same problem. We just followed
> os-brick's lead by adding a change to devstack to explicitly set the
> required config options in nova.conf to change privsep to use rootwrap
> instead of plain sudo.
> Basically every single user of privsep is likely to face the same
> > So... we have a few options:
> > 1) make an exception here with release notes, because it's the only way
> > to move forward.
> That's quite user hostile I think.
> > 2) have some way for os-brick to use either mode for a transition period
> > (depending on whether privsep is configured to work)
> I'm not sure that's viable - at least for os-vif we started from
> a clean slate to assume use of privsep, so we won't be able to have
> any optional fallback to non-privsep mode.
> > 3) Something else.... ?
> 3) Add an API to oslo.privsep that lets us configure the default
> command to launch the helper. Nova would invoke this on startup
> privsep.set_default_helper("sudo nova-rootwrap ....")
> 4) Have oslo.privsep install a sudo rule that grants permission
> to run privsep-helper, without needing rootwrap.
> 5) Have each user of privsep install a sudo rule to grants
> permission to run privsep-helper with just their specific
> entry point context, without needing rootwrap
> Any of 3/4/5 work out of the box, but I'm probably favouring
> option 4, then 5, then 3.
Yep (3) is quite possible, and the only reason it doesn't just do this
already is because there's no way to find the name of the rootwrap command
to use (from any library, privsep or os-brick) - and I was never very happy
with the current need to specify a command line in oslo.config purely for
this lame reason.
As Sean points out, all the others involve some sort of configuration
change preceding the code. I had imagined rollouts would work by pushing
out the harmless conf or sudoers change first, but hadn't appreciated the
strict change phases imposed by grenade (and ourselves).
If all "end-application" devs are happy calling something like (3) before
the first privileged operation occurs, then we should be good. I might
even take the opportunity to phrase it as a general privsep.init()
function, and then we can use it for any other top-of-main()
privilege-setup steps that need to be taken in the future.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev