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

[Matt Riedemann]

On 3/22/2016 5:37 PM, Angus Lees wrote:

On Sat, 19 Mar 2016 at 06:27 Matt Riedemann > 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 

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

[Angus Lees]

On Sat, 19 Mar 2016 at 06:27 Matt Riedemann 
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

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

[Matt Riedemann]

On 2/25/2016 5:35 PM, Angus Lees wrote:

On Fri, 26 Feb 2016 at 01:28 John Garbutt > wrote:

Agreed with the concerns here, but I thought these are the same we
raised at the midcycle.


Yes, afaik everything is exactly as we discussed and following the
direction we agreed at Nova+CInder mid-cycles.

In hindsight, we probably should also have nominated 2x cores from each
of cinder/nova who were willing to be aware of the situation and review
the resulting change - before actually embarking on the work.  As it is,
the clock is striking noon and the street suddenly contains nothing but
tumbleweeds :-P

  - 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



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?


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?


[1] 
https://review.openstack.org/#/c/277670/5/etc/nova/rootwrap.d/compute.filters


--

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

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

[Sean McGinnis]

On Thu, Feb 25, 2016 at 02:26:49PM +, John Garbutt wrote:
> 
> My understanding of what came out of the midcycle was:
> * current rootwrap system horribly breaks upgrade
> * adopting privsep in this "sudo" like form fixes upgrade
> * this approach is much lower risk than a full conversion at this
> point in the release
> * security wise its terrible, but then the current rules don't buy us
> much anyhow
> * makes it easier to slowly transition to better privsep integration
> * all seems better than reverting os-brick integration to fix upgrade issues
> 
> Now at this point, we are way closer to release, but I want to check
> we are making the correct tradeoff here.
> 
> Maybe the upgrade problem is not too bad this release, as the hard bit
> was done with the last upgrade? Or is that total nonsense?

We did have a couple cores watching this this cycle. Walt Boring has
been heavily involved working on this, and I've been waiting to see the
progress.

I think what it ultimately came down to is that it took longer than
expected, and it wasn't until after we cut the "final" os-brick Mitaka
release that some of the blocking issues were worked out with using
privsep.

Given that it has taken this long to get things working, along with how
close we are to M-3, I'm very hesitant to allow this through with very
little runtime.

We really are in a much better position this time around in that there
hasn't been anything added to the rootwrap filters that requires
matching changes in Cinder and Nova. So we should be able to use a mix
of Liberty and Mitaka services without fear of incompatibility.

I do want to see the patches to add the privsep wrapper to rootwrap go
in to Cinder and Nova, even though the official Mitaka os-brick won't be
using it. That should allow us to upgrade os-brick after release without
needing a backported change to the services to allow it.

Sean (smcginnis)

__
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

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

[Angus Lees]

On Fri, 26 Feb 2016 at 01:28 John Garbutt  wrote:

> Agreed with the concerns here, but I thought these are the same we
> raised at the midcycle.
>

Yes, afaik everything is exactly as we discussed and following the
direction we agreed at Nova+CInder mid-cycles.

In hindsight, we probably should also have nominated 2x cores from each of
cinder/nova who were willing to be aware of the situation and review the
resulting change - before actually embarking on the work.  As it is, the
clock is striking noon and the street suddenly contains nothing but
tumbleweeds :-P

 - 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

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

[John Garbutt]

On 25 February 2016 at 05:32, Angus Lees  wrote:
> (Reposting my reply to your gerrit comment here as well - conversation will
> probably be easier here than in gerrit)
>
> On Thu, 25 Feb 2016 at 00:07 Duncan Thomas  wrote:
>>
>> My (negative) feedback is on the review - I'm really not sure that this
>> matches what I understood the vision of privsep to be at all.
>>
>> - If this is the vision / the new vision then I think it is majorly
>> flawed.
>>
>> - If it is skipping the vision in the name of expediency of
>> implementation, then I think it has gone too far in that direction and we've
>> better off holding off one more cycle and putting it in next cycle instead
>> with a touch more purity of vision.
>>
>> Apologies since you've clearly put work into it, and I should have
>> provided such feedback earlier.
>
>
> Yes, I agree with your concerns 100% and I'm actually quite glad that you
> also understand that this isn't a very satisfying use of privsep.
>
> Better uses of privsep would look more like
> https://review.openstack.org/#/c/258252/ - but they're slow to write since
> they typically involve quite a bit of refactoring of code in order to move
> the trust boundary to a useful point up the call stack.  For os-brick in
> particular, I found it quite difficult/risky performing such code refactors
> without an easy way to actually test the affected low-level device
> manipulation.
>
> At the nova mid-cycle (and again in the nova-cinder VC conversation you were
> part of), it was decided that the difficulties in merging the os-brick
> rootwrap filters into nova (and I presume cinder) were too urgent to wait
> for such a slow os-brick refactoring process.  The conclusion we reached was
> that we would do a quick+dirty rootwrap drop-in replacement that effectively
> just ran commands as root for Mitaka, and then we would come back and
> refactor various codepaths away from that mechanism over time.  This is that
> first quick+dirty change.
> I tried to capture that in the commit description, but evidently did a poor
> job - if the above makes it any clearer to you, I'd welcome any suggested
> rewording for the commit description.
>
> TL;DR: what this buys us is the ability to use new/different command lines
> in os-brick without having to go through a rootwrap filters merge in
> downstream projects (and it is also that first baby step towards a
> technology that will allow something better in the future).

Agreed with the concerns here, but I thought these are the same we
raised at the midcycle.

My understanding of what came out of the midcycle was:
* current rootwrap system horribly breaks upgrade
* adopting privsep in this "sudo" like form fixes upgrade
* this approach is much lower risk than a full conversion at this
point in the release
* security wise its terrible, but then the current rules don't buy us
much anyhow
* makes it easier to slowly transition to better privsep integration
* all seems better than reverting os-brick integration to fix upgrade issues

Now at this point, we are way closer to release, but I want to check
we are making the correct tradeoff here.

Maybe the upgrade problem is not too bad this release, as the hard bit
was done with the last upgrade? Or is that total nonsense?

Thanks,
johnthetubaguy

>> On 24 February 2016 at 14:59, Michał Dulko  wrote:
>>>
>>> On 02/24/2016 04:51 AM, Angus Lees wrote:
>>> > Re: https://review.openstack.org/#/c/277224
>>> >
>>> > Most of the various required changes have flushed out by now, and this
>>> > change now passes the dsvm-full integration tests(*).
>>> >
>>> > (*) well, the experimental job anyway.  It still relies on a
>>> > merged-but-not-yet-released change in oslo.privsep so gate + 3rd party
>>> > won't pass until that happens.
>>> >
>>> > What?
>>> > This change replaces os-brick's use of rootwrap with a quick+dirty
>>> > privsep-based drop-in replacement.  Privsep doesn't actually provide
>>> > much security isolation when used in this way, but it *does* now run
>>> > commands with CAP_SYS_ADMIN (still uid=0/gid=0) rather than full root
>>> > superpowers.  The big win from a practical point of view is that it
>>> > also means os-brick's rootwrap filters file is essentially deleted and
>>> > no longer has to be manually merged with downstream projects.
>>> >
>>> > Code changes required in nova/cinder:
>>> > There is one change each to nova+cinder to add the relevant
>>> > privsep-helper command to rootwrap filters, and a devstack change to
>>> > add a nova.conf/cinder.conf setting.  That's it - this is otherwise a
>>> > backwards/forwards compatible change for nova+cinder.
>>> >
>>> > Deployment changes required in nova/cinder:
>>> > A new "privsep_rootwrap.helper_command" needs to be defined in
>>> > nova/cinder.conf (default is something sensible using sudo), and
>>> > rootwrap filters or sudoers updated depending on the exact command
>>> > chosen.  Be aware 

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

[Angus Lees]

(Reposting my reply to your gerrit comment here as well - conversation will
probably be easier here than in gerrit)

On Thu, 25 Feb 2016 at 00:07 Duncan Thomas  wrote:

> My (negative) feedback is on the review - I'm really not sure that this
> matches what I understood the vision of privsep to be at all.
>
> - If this is the vision / the new vision then I think it is majorly
> flawed.
>
> - If it is skipping the vision in the name of expediency of
> implementation, then I think it has gone too far in that direction and
> we've better off holding off one more cycle and putting it in next cycle
> instead with a touch more purity of vision.
>
> Apologies since you've clearly put work into it, and I should have
> provided such feedback earlier.
>

Yes, I agree with your concerns 100% and I'm actually quite glad that you
also understand that this isn't a very satisfying use of privsep.

Better uses of privsep would look more like
https://review.openstack.org/#/c/258252/ - but they're slow to write since
they typically involve quite a bit of refactoring of code in order to move
the trust boundary to a useful point up the call stack.  For os-brick in
particular, I found it quite difficult/risky performing such code refactors
without an easy way to actually test the affected low-level device
manipulation.

At the nova mid-cycle (and again in the nova-cinder VC conversation you
were part of), it was decided that the difficulties in merging the os-brick
rootwrap filters into nova (and I presume cinder) were too urgent to wait
for such a slow os-brick refactoring process.  The conclusion we reached
was that we would do a quick+dirty rootwrap drop-in replacement that
effectively just ran commands as root for Mitaka, and then we would come
back and refactor various codepaths away from that mechanism over time.
This is that first quick+dirty change.
I tried to capture that in the commit description, but evidently did a poor
job - if the above makes it any clearer to you, I'd welcome any suggested
rewording for the commit description.

TL;DR: what this buys us is the ability to use new/different command lines
in os-brick without having to go through a rootwrap filters merge in
downstream projects (and it is also that first baby step towards a
technology that will allow something better in the future).


Please continue to ask questions, since I know very few people have
actually looked at any of privsep nor the os-brick change until now.

 - Gus


> On 24 February 2016 at 14:59, Michał Dulko  wrote:
>
>> On 02/24/2016 04:51 AM, Angus Lees wrote:
>> > Re: https://review.openstack.org/#/c/277224
>> >
>> > Most of the various required changes have flushed out by now, and this
>> > change now passes the dsvm-full integration tests(*).
>> >
>> > (*) well, the experimental job anyway.  It still relies on a
>> > merged-but-not-yet-released change in oslo.privsep so gate + 3rd party
>> > won't pass until that happens.
>> >
>> > What?
>> > This change replaces os-brick's use of rootwrap with a quick+dirty
>> > privsep-based drop-in replacement.  Privsep doesn't actually provide
>> > much security isolation when used in this way, but it *does* now run
>> > commands with CAP_SYS_ADMIN (still uid=0/gid=0) rather than full root
>> > superpowers.  The big win from a practical point of view is that it
>> > also means os-brick's rootwrap filters file is essentially deleted and
>> > no longer has to be manually merged with downstream projects.
>> >
>> > Code changes required in nova/cinder:
>> > There is one change each to nova+cinder to add the relevant
>> > privsep-helper command to rootwrap filters, and a devstack change to
>> > add a nova.conf/cinder.conf setting.  That's it - this is otherwise a
>> > backwards/forwards compatible change for nova+cinder.
>> >
>> > Deployment changes required in nova/cinder:
>> > A new "privsep_rootwrap.helper_command" needs to be defined in
>> > nova/cinder.conf (default is something sensible using sudo), and
>> > rootwrap filters or sudoers updated depending on the exact command
>> > chosen.  Be aware that any commands will now be run with CAP_SYS_ADMIN
>> > (only), and if that's insufficient for your hardware/drivers it can be
>> > tweaked with other oslo_config options.
>> >
>> > Risks:
>> > The end-result is still just running the same commands as before, via
>> > a different path - so there's not a lot of adventurousness here.  The
>> > big behavioural change is CAP_SYS_ADMIN, and (as highlighted above)
>> > it's conceivable that the driver for some exotic os-brick/cinder
>> > hardware out there wants something more than that.
>> >
>> > Work remaining:
>> > - global-requirements change needed (for os-brick) once the latest
>> > oslo.privsep release is made
>> > - cinder/nova/devstack changes need to be merged
>> > - after the above, the os-brick gate integration jobs will be able to
>> > pass, and it can be merged
>> > - If we want to *force* 

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

[Michał Dulko]

On 02/24/2016 04:51 AM, Angus Lees wrote:
> Re: https://review.openstack.org/#/c/277224
>
> Most of the various required changes have flushed out by now, and this
> change now passes the dsvm-full integration tests(*).
>
> (*) well, the experimental job anyway.  It still relies on a
> merged-but-not-yet-released change in oslo.privsep so gate + 3rd party
> won't pass until that happens.
>
> What?
> This change replaces os-brick's use of rootwrap with a quick+dirty
> privsep-based drop-in replacement.  Privsep doesn't actually provide
> much security isolation when used in this way, but it *does* now run
> commands with CAP_SYS_ADMIN (still uid=0/gid=0) rather than full root
> superpowers.  The big win from a practical point of view is that it
> also means os-brick's rootwrap filters file is essentially deleted and
> no longer has to be manually merged with downstream projects.
>
> Code changes required in nova/cinder:
> There is one change each to nova+cinder to add the relevant
> privsep-helper command to rootwrap filters, and a devstack change to
> add a nova.conf/cinder.conf setting.  That's it - this is otherwise a
> backwards/forwards compatible change for nova+cinder.
>
> Deployment changes required in nova/cinder:
> A new "privsep_rootwrap.helper_command" needs to be defined in
> nova/cinder.conf (default is something sensible using sudo), and
> rootwrap filters or sudoers updated depending on the exact command
> chosen.  Be aware that any commands will now be run with CAP_SYS_ADMIN
> (only), and if that's insufficient for your hardware/drivers it can be
> tweaked with other oslo_config options.
>
> Risks:
> The end-result is still just running the same commands as before, via
> a different path - so there's not a lot of adventurousness here.  The
> big behavioural change is CAP_SYS_ADMIN, and (as highlighted above)
> it's conceivable that the driver for some exotic os-brick/cinder
> hardware out there wants something more than that.
>
> Work remaining:
> - global-requirements change needed (for os-brick) once the latest
> oslo.privsep release is made
> - cinder/nova/devstack changes need to be merged
> - after the above, the os-brick gate integration jobs will be able to
> pass, and it can be merged
> - If we want to *force* the new version of os-brick, we then need an
> appropriate global-requirements os-brick bump
> - Documentation, release notes, etc
>
> I'll continue chewing through those remaining work items, but
> essentially this is now in your combined hands to prioritise for
> mitaka as you deem appropriate.
>
>  - Gus
>

It seems too me that risks are higher than advantages. Moreover final
release for libraries like os.brick should happen in just 2 days and I
don't believe we have time to get every part of the job merged given how
long TODO list is.

Just my $0.02.

__
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

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

[Angus Lees]

Re: https://review.openstack.org/#/c/277224

Most of the various required changes have flushed out by now, and this
change now passes the dsvm-full integration tests(*).

(*) well, the experimental job anyway.  It still relies on a
merged-but-not-yet-released change in oslo.privsep so gate + 3rd party
won't pass until that happens.

What?
This change replaces os-brick's use of rootwrap with a quick+dirty
privsep-based drop-in replacement.  Privsep doesn't actually provide much
security isolation when used in this way, but it *does* now run commands
with CAP_SYS_ADMIN (still uid=0/gid=0) rather than full root superpowers.
The big win from a practical point of view is that it also means os-brick's
rootwrap filters file is essentially deleted and no longer has to be
manually merged with downstream projects.

Code changes required in nova/cinder:
There is one change each to nova+cinder to add the relevant privsep-helper
command to rootwrap filters, and a devstack change to add a
nova.conf/cinder.conf setting.  That's it - this is otherwise a
backwards/forwards compatible change for nova+cinder.

Deployment changes required in nova/cinder:
A new "privsep_rootwrap.helper_command" needs to be defined in
nova/cinder.conf (default is something sensible using sudo), and rootwrap
filters or sudoers updated depending on the exact command chosen.  Be aware
that any commands will now be run with CAP_SYS_ADMIN (only), and if that's
insufficient for your hardware/drivers it can be tweaked with other
oslo_config options.

Risks:
The end-result is still just running the same commands as before, via a
different path - so there's not a lot of adventurousness here.  The big
behavioural change is CAP_SYS_ADMIN, and (as highlighted above) it's
conceivable that the driver for some exotic os-brick/cinder hardware out
there wants something more than that.

Work remaining:
- global-requirements change needed (for os-brick) once the latest
oslo.privsep release is made
- cinder/nova/devstack changes need to be merged
- after the above, the os-brick gate integration jobs will be able to pass,
and it can be merged
- If we want to *force* the new version of os-brick, we then need an
appropriate global-requirements os-brick bump
- Documentation, release notes, etc

I'll continue chewing through those remaining work items, but essentially
this is now in your combined hands to prioritise for mitaka as you deem
appropriate.

 - 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