Re: ACLs for GIT

Martin L Resnick [off-list ref] writes:

On 05/15/2011 04:15 PM, Magnus Bäck wrote:

quoted

On Sunday, May 15, 2011 at 21:24 CEST,
      Martin L Resnick[off-list ref]  wrote:

quoted

Is anyone working on adding access control to GIT ?

I'm looking for the Subversion equivalent of mod_authz_svn.
I need to restrict read access of ITAR documents that are
scattered throughout the source tree.
This restriction would need to deny fetch of the ITAR
documents yet allow fetch of any other files.

Looking through the source code it would seem that
putting a hook call in the fetch-pack code would do it.

I doubt it would make sense to put per-file permissions in Git
as it doesn't version files but the complete state of a workspace.
Even if you manage to hack the pack code to not include certain
blobs when certain users ask for them, what would those users
do when they want to create new commits based on commits where
blobs are missing? Or would you send the protected blobs but
replace their contents? Then Git would complain about that.

However, both Gerrit Code Review and Gitolite offer per-branch
permissions, so if it would be possible to put these files on
branches of their own these tools would help.

You pointed out some hurdles I'll have to think about
(blocked files not matching the SHA and so can't be committed).

As to why I want to do this consider NSA non-export rules.
Our application would be built with NSA encryption
but we have foreign nationals working on the code
and so they are not permitted to see that part.
The makefiles look to see if the NSA encryption code file
is there and link it in. If not a stub is used.

You have to remember that with exception of submodules, which can be
fetched or not, all operations between repositories operate on whole
tree basis.  The commit in Git (i.e. a single revision) always contain
_all_ the files in repository (with exception of submodules).

ACL in e.g. Gitolite allow to refuse push if there are changes to
specified paths (per-file access control), but it wouldn't and
couldn't preent from viewing such "restricted" files.


1. What you can do is manage two unrelated branches (without common
ancestor one orphan to the other), "private" and "public".  You do
public work on branches starting on public branch, and merge both to
public and private, and you do private work on branches starting at
private branch, and merge only to private.  The public publishing
repository (e.g. on GitHub or repo.or.cz) would have only "public"
branch, while private clone (e.g. on intranet, or on private
repository on GitHub) would have both branches.

2. Another solution that could work is to have stubs for "restricted"
files, and in private repository use git-replace mechanism to replace
those stubs with "restricted" contents.  Again in public publishing
repository you woldn't have refs/replace published, while in private
one you would have refs/replace and git would show "restricted"
contents replacing stubs.  NOT TESTED!.

3. As other wrote, you can have yet another solution: use submodules.
You would put "restricted" contents in submodule, and just not make
repository that makes submodule public.  What would be visible would
be only SHA-1 of contents in supermodule.  This assumes that you can
disentanle files into submodules (loose connection)...

-- 
Jakub Narebski
Poland
ShadeHawk on #git