[openstack-dev] [rootwrap] rootwrap and libraries - RFC
Joshua Harlow
harlowja at outlook.com
Thu Sep 10 17:54:51 UTC 2015
Just out of curiosity, not 100% related to this thread, but other
applications also bundle configuration files (for example heat templates
@ https://github.com/openstack/magnum/tree/master/magnum/templates)
Should there be some guidelines on how these config files are packaged
and distributed for these projects as well (ie also use pkgutil...);
probably a good idea to have one so that
distributors/installers/packaging folk don't have to do something custom
when packaging these applications/libraries.
-Josh
Thierry Carrez wrote:
> 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).
>
More information about the OpenStack-dev
mailing list