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