Open Stack

On 09/10/2015 08:23 AM, Thierry Carrez wrote:
> Sean Dague wrote:
>> Right now, they are all a bunch of files, they can be anywhere. And then
>> you have other files that have to reference these files by path, which
>> can be anywhere. We could just punt in that part and say "punt! every
>> installer and configuration management install needs to solve this on
>> their own." I'm not convinced that's a good answer. The os-brick filters
>> aren't really config. If you change them all that happens is
>> terribleness. Stuff stops working, and you don't know why. They are data
>> to exchange with another process about how to function. Honestly, they
>> should probably be python code that's imported by rootwrap.
>>
>> Much like the issues around clouds failing when you try to GET /v2 on
>> the Nova API (because we have a bunch of knobs you have to align for SSL
>> termination, and a bunch of deployers didn't), I don't think we should
>> be satisfied with "there's a config for that!" when all that config
>> means is that someone can break their configuration if they don't get it
>> exactly right.
> 
> My quick 2cents on this. Rootwrap was designed as a generic solution to
> wrap privileged calls. That's why filter files are part of its
> "configuration". The problem is, OpenStack needs a pretty precise set of
> those filters to be "configured" to run properly. So it's configuration
> for rootwrap, but not "configuration" for OpenStack.
> 
> The way it was supposed to work out was that you would have a single
> rootwrap on nodes and every component on that node needing filters would
> drop them in some unique location. A library is just another component
> needing filters, so os-brick could just deploy a few more filters on
> nodes where it's installed.
> 
> The trick is, to increase "security" we promoted usage of per-project
> directories (so that Nova only has access to Nova privileged commands),
> which translated into using a specific config file for Nova rootwrap
> pointing to Nova filters. Now if we are willing to sacrifice that, we
> could have a single directory per-node (/usr/share/rootwrap instead of
> /usr/share/*/rootwrap) that makes most of the interpolation you're
> describing unnecessary.
> 
> Alternatively you could keep project-specific directories and have
> os-brick drop symbolic links to its filters into both nova and
> cinder-specific directories. It's slightly less flexible (since the lib
> now has to know what consumes it) but keeps you from sacrificing "security".
> 
> Now another problem you're describing is that there is no single place
> where those filters end up, depending on the way the projects (or libs)
> are packaged and installed. And it's up to the distros to "fix" the
> filters_path in the configuration file so that it points to every single
> place where those end up. It's a problem (especially when you start to
> install things using multiple concurrent packaging systems), but it's
> not exactly new -- it's just that libraries shipping fliters file are
> even more likely to ship their filters somewhere weird. So maybe we can
> continue to live with that problem we always had, until the privsep
> system completely replaces rootwrap ?

I do get this is where we came from. I feel like this doesn't really
address or understand that things are actually quite different when it
comes to libraries doing rootwrap. We've spent weeks attempting various
work arounds, and for Liberty just punted and said "os-brick, cinder,
and nova all must upgrade exactly at the same time". Because that's the
only solution that doesn't require pages of documentation that
installers will get wrong some times.

I don't feel like that's an acceptable solution. And it also means that
"living" with it means that next cycle we're going to have to say "nova,
neutron, cinder, os-brick, and vif library must all upgrade at exactly
the same time". Which is clearly not a thing we want. Had we figured out
this rootwrap limitation early, os-brick would never have been put into
Nova because it makes the upgrade process demonstrably worse and more
fragile.

	-Sean

-- 
Sean Dague
http://dague.net