Re: Shared repositories no longer securable against privilege escalation

Michael Haggerty <mhagger@alum.mit.edu> writes:

If you call that "pointing out", I can't resist pointing out that you are utterly *wrong* ;-)

For one thing, HEAD.lock being the only reported case does not mean "special refs" is the only thing, and more importantly, it will stay to be the only thing, that would want to write directly underneath $GIT_DIR directory. We may want to add a feature to store push certificates whenever a signed push is made, and we are free to decide that directly underneath $GIT_DIR is the place to do so.

Also, with your same logic, you could also say that the real bug is not in the refs subsystem but is in the lockfile subsystem. If it did not use $GIT_DIR/$thing.lock when locking $GIT_DIR/$thing, and instead it used $GIT_DIR/lock/$thing to do so, you wouldn't have needed to be able to create $GIT_DIR/HEAD.lock.

I _think_ the real bug is that somehow a user got a wrong impression that directly underneath $GIT_DIR/ is somehow different from its subdirectory and it is OK to make the directory unwritable. I do not think we never intended to give such a promise, but there may be a documentation bug that gives the wrong impression, which we may have to fix.

We do try to make sure that in a read-only repository $GIT_DIR/ and everything underneath can be read-only (and if that is not the case, you found a bug), but even in that case, we do not special case $GIT_DIR/ itself and its subdirectories.