Re: Shared repositories no longer securable against privilege escalation

On Fri, Mar 17, 2017 at 1: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 >

Re: Shared repositories no longer securable against privilege escalation

W dniu 17.03.2017 o 18:12, Joe Rayhawk pisze: > Quoting Michael Haggerty (2017-03-17 05:07:36) >> >> 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

Re: Shared repositories no longer securable against privilege escalation

Michael Haggerty writes: > 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

Re: Shared repositories no longer securable against privilege escalation

Joe Rayhawk writes: > that, at least on base POSIX, using --shared to share a repository > between multiple UIDs literally eliminates the purpose of having > multiple UIDs. I do not think the world is _that_ blank-and-white. If you cannot trust those who push to the

Re: Shared repositories no longer securable against privilege escalation

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

Re: Shared repositories no longer securable against privilege escalation

Quoting Junio C Hamano (2017-03-17 08:26:39) > Michael Haggerty writes: > 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

Re: Shared repositories no longer securable against privilege escalation

Michael Haggerty writes: > (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.) If you call that "pointing out", I can't resist pointing out that you are utterly *wrong*

Re: Shared repositories no longer securable against privilege escalation

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

Shared repositories no longer securable against privilege escalation

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