On 03/17/2017 01:23 AM, Joe Rayhawk wrote: > Git has started requiring write access to the root of bare repositories > in order to create /HEAD.lock. This is a major security problem in > shared environments as it also entails control over the /config link > i.e. core.hooksPath. Permission to write objects and update refs should > be entirely separate from permission to edit hook execution logic. > > Given that /HEAD is not dynamically modified in the normal lifetimes of > bare repositories, /HEAD.lock creation failure should probably be, at > worst, an ignorable soft failure. Alternatively, some form of stale > lockfile handling (currently there is none) could be made to work with > a writable HEAD.lock in a read-only bare repository. > > Obigatory HEAD.lock creation was introduced in the following commit: > > commit 92b1551b1d407065f961ffd1d972481063a0edcc > Author: Michael Haggerty <mhagger@xxxxxxxxxxxx> > Date: Mon Apr 25 15:56:07 2016 +0200 > > refs: resolve symbolic refs first Thanks for the report. This is indeed a problem for people who want to set restrictive privileges on $GIT_DIR. I'd never thought of that use case, but it makes sense. Is this practice recommended somewhere or required by any Git hosting tools? (I'm curious how prevalent it is.) The locking was added intentionally, to ensure that the reflog for `HEAD` is written safely. But the code didn't do that prior to the commit that you referenced, so (as a special case) ignoring failures to lock `HEAD` due to insufficient permission is probably a reasonable compromise. I think the special case could be restricted even further to when `HEAD` has the `REF_LOG_ONLY` flag in the reference transaction. I don't think that `HEAD` would ever show up in a transaction solely to verify its old value in a typical server scenario, but if so, that situation could be special cased too. (I can't resist pointing out that the *real* bug is storing special references like `HEAD` in the top level of $GIT_DIR, but that can't be changed now.) Michael