Re: ACLs for GIT
- From
Sitaram Chamarty <sitaramc@gmail.com>
- Date
- May 17, 2011, 01:32 UTC
- Message-ID
- <BANLkTikwEivOiQVV-B=g3pP_StXAa8CVwg@mail.gmail.com>
- In-Reply-To
- <4DD12517.1000308@bbn.com>
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, 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...).
regards
sitaram
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 ;-)