Re: ACLs for GIT

From: Shawn Pearce <spearce@spearce.org>
Date: May 17, 2011, 01:49 UTC
Message-ID: <BANLkTi=9vp+ibVa3tQzXbZSeYATKwmF60Q@mail.gmail.com>
In-Reply-To: <BANLkTikwEivOiQVV-B=g3pP_StXAa8CVwg@mail.gmail.com>

On Mon, May 16, 2011 at 18:32, Sitaram Chamarty <sitaramc@gmail.com> wrote:

Show 15 quoted lines

> On Mon, May 16, 2011 at 6:52 PM, Martin L Resnick <mresnick@bbn.com> wrote:
>> Thanks for the reply.
>>
>> But gitolite would only work to deny reads on a repository or ref basis
>> not a pathname level.
>
> I notice the original question has been answered, so this email is
> just for the record.
>
> Gitolite does not do any access control on *read* access (fetch,
> clone).  It can only do that on *write*s (push).
>
> Gerrit does that because they've reimplemented git itself and have
> coded that into their git engine somehow.  I believe they had to
> implement a callback from jgit to gerrit for the fetch,

Yes, we do.

> and deal with
> evil clients that might try to read an object by pushing a supposed
> change on top of a SHA that they know but don't actually have. (Or
> something like that; I'm not real clear on this...).

Yes, we also have protections for this. Users cannot push objects that reference objects they are not allowed to read. This check needs to be done for delta bases as well as commit tree/parent pointers, and tree entries. Its not difficult, but its not as simple as just limiting the branch names shown to upload-pack.

> PS: Gitolite does have unreleased code to do this but it's a hack with
> several limitations.  Gitolite makes a temp "clone -l", deletes all
> refs from it that the user has no access to, then redirects the
> git-upload-pack to that repo instead ;-)

Cute hack. Doesn't prevent the evil client from making an indirect reference to something you shouldn't have. :-)

-- 
Shawn.