Quoting Michael Haggerty (2017-03-17 05:07:36) > 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. > > 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.) I had to work out the practice for my own management engine; I have since deployed it to around eight different mixed-use multi-user operations, the most significant of which is Freedesktop.org. Without this practice, core.sharedRepository is an enormous liability of a feature. I can't speak to whether anyone but me ever noticed, what with mixed-use multi-user POSIX environments becoming increasingly rare. > 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. Hooray! > (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.) Yeah, putting refs outside of refs/ is conceptually pretty nutty.
Attachment:
signature.asc
Description: signature