Re: ACLs for GIT

On Mon, May 16, 2011 at 18:32, Sitaram Chamarty [off-list ref] wrote:

On Mon, May 16, 2011 at 6:52 PM, Martin L Resnick [off-list ref] wrote:

quoted

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.