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 ? > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
