Open Stack

Excerpts from Thierry Carrez's message of 2015-09-10 14:23:34 +0200:
> 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.

That makes them sound like data, not configuration. If that's the case,
Python's pkgutil module is an existing API for putting a data file
inside a library and then accessing it. Maybe we should look at moving
the files to a place that lets us use that, instead of requiring any
deployer-based configuration at all. Combining that with the "symbolic"
suggestion from Sean, we would use the package name as the symbol and
there would be a well-defined resource name within that package to use
with pkgutil.get_data() [1].

Doug

[1] https://docs.python.org/2.7/library/pkgutil.html#pkgutil.get_data

> 
> 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 ?
>