Excerpts from Sean Dague's message of 2013-12-06 09:47:03 -0800: > So it still seems that we are at an impasse here on getting new olso > lockutils into cinder because it doesn't come with a working default. > > As a recap - https://review.openstack.org/#/c/48935/ (that sync) > > is blocked by failing upgrade testing, because lock_path has no default, > so it has to land config changes simultaneously on the commit otherwise > explode cinder on startup (as not setting that variable explodes as a > fatal error). I consider that an upgrade blocker, and am not comfortable > with the work around - https://review.openstack.org/#/c/52070/3 > > I've proposed an oslo patch that would give us a default plus an ERROR > log message if you used it - https://review.openstack.org/#/c/60274/ > > The primary concern here is that it opens up a local DOS attack because > it's a well known directory. This is a valid concern. My feeling is you > are lost anyway if you have malicious users on your system, and if we've > narrowed them down to only DOSing (which there other ways they could do > that), I think we've narrowed the surface enough to make this acceptable > at the ERROR log level. However there are objections, so at this point > it seems like we needed to summarize the state of the world, get this > back onto the list with a more descriptive subject, and see who else > wants to weigh in. >
Sean I respect that pragmatism has to win out over paranoia at some point, and this may very well be that point, so I'm happy to step back from the issue if others feel like we're there. However, I think it is every program's duty to protect itself. Otherwise those programs will be the weak links in the chains that lead to expanded compromise. There are plenty of examples where just the ability to DOS one piece leads to things like being able to then expose further race conditions. "Defense in depth" is something we should always be supporting. How do we handle python requirements changes? At the same point where we pip install -U -r requirements.txt, we can also update the config file, can we not? Or we can at least create /var/run/cinder and make sure it is owned by cinder and has the appropriate permissions. Could we make that the default? That would eliminate the threat, and be a reasonably easy thing for users to make sure is in place well in advance of upgrades. As I've mentioned in the reviews, we have 'fail open' or 'fail closed'. Security wants us to fail closed every time. But sometimes that means trading in too much convenience. I suggest that it is worth it in this case, but I am just one person. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
