Open Stack

(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 <duncan.thomas at gmail.com> 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 <michal.dulko at intel.com> 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* 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-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> --
> Duncan Thomas
>
> Message protected by MailGuard: e-mail anti-virus, anti-spam and content
> filtering.
> http://www.mailguard.com.au/mg
>
> Report this message as spam
> <https://console.mailguard.com.au/ras/1NU0lK0F0b/3bhu1b0Gm5cuxeirJNa32w/2.626>
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160225/7049907b/attachment.html>