Open Stack

Excerpts from Thierry Carrez's message of 2015-09-10 19:35:21 +0200:
> Doug Hellmann wrote:
> > Excerpts from Thierry Carrez's message of 2015-09-10 14:23:34 +0200:
> >> 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].
> 
> That sounds promising. One trick is that it's the consuming application
> that needs to ship the filters, not the library itself (so rootwrap
> would have to look into nova resources, not rootwrap resources). Another
> trick is that it should require root rights (not nova rights) to change
> those resources, otherwise the security model is broken (the whole idea
> of rootwrap being to restrict what a compromised nova user can do to the
> system).

If we put the data file inside the library, it will be installed where
the code lives, so it should have the permission protection we need. The
symbol names passed to rootwrap would be hard-coded inside the
application making the call, so that would also be protected.

Doug