Open Stack

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.