Git and securing a repository

Git and securing a repository

[Gonzalo Garramuño]

I've been using git for some time and love it.  For open source projects 
there's clearly nothing currently better.

However, I am now using git for proprietary elements, which in the 
future I may need or want to partially restrict access to.  The idea 
being that at my company some (junior) developers should not be given 
access to some elements.  That means either that some full git 
repository should be password protected or even portions of the same 
repository.

Another desirable way to protect elements might be only giving 
clone/pull access to a repository (or portion of it) but not permissions 
to push in changes.

I have not seen or read much about how git deals with accesses and 
permissions.  Can anyone point me to some documentation if some or all 
of this is possible?


-- 
Gonzalo Garramuño
ggarra@advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy

Re: Git and securing a repository

[Felipe Balbi]

On Jan 2, 2008 2:13 AM, Gonzalo Garramuño <ggarra@advancedsl.com.ar> wrote:
>
> I've been using git for some time and love it.  For open source projects
> there's clearly nothing currently better.
>
> However, I am now using git for proprietary elements, which in the
> future I may need or want to partially restrict access to.  The idea
> being that at my company some (junior) developers should not be given
> access to some elements.  That means either that some full git
> repository should be password protected or even portions of the same
> repository.
>
> Another desirable way to protect elements might be only giving
> clone/pull access to a repository (or portion of it) but not permissions
> to push in changes.

push access is only available through ssh, so if your developer
doesn't have a ssh account on the server, he can't push code to it

>
> I have not seen or read much about how git deals with accesses and
> permissions.  Can anyone point me to some documentation if some or all
> of this is possible?

it's easy on the full repository case, create different groups and
share git repositories by groups, after that chmod o-rwx -R
/path/to/repository.git.

If a user is not the owner nor is part of that group in particular, it
wouldn't be able to push any code to the repository.

btw, if you don't start git-daemon you could use ssh to pull code as well.

thinking on the partial repository access, maybe git submodule would
help, but i've never used it.

-- 
Best Regards,

Felipe Balbi
felipebalbi@users.sourceforge.net

Re: Git and securing a repository

[Gonzalo Garramuño]

Felipe Balbi wrote:
> 
> it's easy on the full repository case, create different groups and
> share git repositories by groups, after that chmod o-rwx -R
> /path/to/repository.git.
> 

Thanks.  I'll admit what you describe is somewhat discouraging, as what 
you are just describing is just managing user accounts or groups on the 
underlying OS.  That does not extend well to placing code on the net and 
has a bunch of administrative headaches.

I was really looking for a permission based system that was part of git 
itself (and thus more portable and easier to admin), and not the OS. 
Something akin to what perforce or even CVS can do.


-- 
Gonzalo Garramuño
ggarra@advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy

Re: Git and securing a repository

[David Symonds]

On Jan 2, 2008 9:04 PM, Gonzalo Garramuño <ggarra@advancedsl.com.ar> wrote:
> Felipe Balbi wrote:
> >
> > it's easy on the full repository case, create different groups and
> > share git repositories by groups, after that chmod o-rwx -R
> > /path/to/repository.git.
> >
>
> Thanks.  I'll admit what you describe is somewhat discouraging, as what
> you are just describing is just managing user accounts or groups on the
> underlying OS.  That does not extend well to placing code on the net and
> has a bunch of administrative headaches.
>
> I was really looking for a permission based system that was part of git
> itself (and thus more portable and easier to admin), and not the OS.
> Something akin to what perforce or even CVS can do.

You can do arbitrarily-fine-grained authentication via the pre-receive hook.


Dave.

Re: Git and securing a repository

[Gonzalo Garramuño]

David Symonds wrote:
> 
> You can do arbitrarily-fine-grained authentication via the pre-receive hook.
> 

Can you provide some more info?  Looking at the kernel.org git docs, the 
pre-receive hook seems very limited as no parameters are allowed.  So 
I'm not sure how an authentication system could be created.

It also seems to be a push hook only (not invoked on pulls).



-- 
Gonzalo Garramuño
ggarra@advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy

Re: Git and securing a repository

[Jakub Narebski]

Gonzalo Garramuño <ggarra@advancedsl.com.ar> writes:

> David Symonds wrote:
>>
>> You can do arbitrarily-fine-grained authentication via the
>> pre-receive hook.
>>
> 
> Can you provide some more info?  Looking at the kernel.org git docs,
> the pre-receive hook seems very limited as no parameters are allowed.
> So I'm not sure how an authentication system could be created.
> 
> It also seems to be a push hook only (not invoked on pulls).

Some of read-only (fetch only) access protocols do not support
authentication: http, ftp, rsync, git. Authentication is provided only
for access via ssh and for push via https (WebDAV).

There is example update hook in contrib/hooks, named update-paranoid,
which could be base of what you want. Note that you probably rather
use newer pre-receive hook instead of older update hook.

AFAIK both update and pre-receive hooks are invoked also on fetch...
but I might be mistaken.
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Git and securing a repository

[Shawn O. Pearce]

Jakub Narebski <jnareb@gmail.com> wrote:
> Gonzalo Garramuño <ggarra@advancedsl.com.ar> writes:
> > David Symonds wrote:
> >>
> >> You can do arbitrarily-fine-grained authentication via the
> >> pre-receive hook.
> > 
> > Can you provide some more info?  Looking at the kernel.org git docs,
> > the pre-receive hook seems very limited as no parameters are allowed.
> > So I'm not sure how an authentication system could be created.

If you read the documentation carefully you will note that the
pre-receive hook receives input on stdin; 1 line of data per ref
that is being pushed with the old/new SHA-1 values and the ref
name.  The hook exits 0 to allow all changes to take place and
can exit > 0 to abort and disallow all updates.

This is a "batch" form of the update hook.

> > It also seems to be a push hook only (not invoked on pulls).
> 
> Some of read-only (fetch only) access protocols do not support
> authentication: http, ftp, rsync, git. Authentication is provided only
> for access via ssh and for push via https (WebDAV).

Authentication could be supported for http, ftp, or ssh based fetch,
but there you are relying on the server that provides access to do
the authentication and authorization for you; typically that will
boil down to UNIX filesystem read permission.  Though with HTTP
and a fancy Apache config it doesn't have to be.
 
> There is example update hook in contrib/hooks, named update-paranoid,
> which could be base of what you want. Note that you probably rather
> use newer pre-receive hook instead of older update hook.

update-paranoid uses the update hook rather than pre-receive to
allow it to allow/deny on a per-ref basis.  One of the flaws of
the pre-receive hook "API" is it is an all-or-nothing proposition.

So by using the "older" update hook update-paranoid can make its
decision on a per-ref basis and allow some refs to change in this
push but abort/deny others.  I find that useful but not everyone
might.
 
> AFAIK both update and pre-receive hooks are invoked also on fetch...
> but I might be mistaken.

No, they are *not* invoked on fetch.  Currently no hooks execute
during fetch; either on the server *or* on the client side of
the connection.

-- 
Shawn.

Re: Git and securing a repository

[Bruno Cesar Ribas]

I lost ohter mails, so replying here =)

I wrote sometime ago i wrote[1] a bunch of BASH scripts to manage SSH_ACL and "internal"
plugin is to manage GIT repositories. 
It is simple and you can grant access to a user for R or W. And there is NO
need to create more users just a "git" user is nice.

I'm re-writing it to become more flexible about configuration and to add more
plugins.

We are using it at C3SL[2] to manage our projects and Write permissions are
set because we don't want some developers pushing to anothers projects.

bruno

[1]http://www.inf.ufpr.br/ribas/ssh_acl/
[2]http://www.c3sl.ufpr.br
On Wed, Jan 02, 2008 at 10:58:38PM -0500, Shawn O. Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
> > Gonzalo Garramuño <ggarra@advancedsl.com.ar> writes:
> > > David Symonds wrote:
> > >>
> > >> You can do arbitrarily-fine-grained authentication via the
> > >> pre-receive hook.
> > > 
> > > Can you provide some more info?  Looking at the kernel.org git docs,
> > > the pre-receive hook seems very limited as no parameters are allowed.
> > > So I'm not sure how an authentication system could be created.
> 
> If you read the documentation carefully you will note that the
> pre-receive hook receives input on stdin; 1 line of data per ref
> that is being pushed with the old/new SHA-1 values and the ref
> name.  The hook exits 0 to allow all changes to take place and
> can exit > 0 to abort and disallow all updates.
> 
> This is a "batch" form of the update hook.
> 
> > > It also seems to be a push hook only (not invoked on pulls).
> > 
> > Some of read-only (fetch only) access protocols do not support
> > authentication: http, ftp, rsync, git. Authentication is provided only
> > for access via ssh and for push via https (WebDAV).
> 
> Authentication could be supported for http, ftp, or ssh based fetch,
> but there you are relying on the server that provides access to do
> the authentication and authorization for you; typically that will
> boil down to UNIX filesystem read permission.  Though with HTTP
> and a fancy Apache config it doesn't have to be.
>  
> > There is example update hook in contrib/hooks, named update-paranoid,
> > which could be base of what you want. Note that you probably rather
> > use newer pre-receive hook instead of older update hook.
> 
> update-paranoid uses the update hook rather than pre-receive to
> allow it to allow/deny on a per-ref basis.  One of the flaws of
> the pre-receive hook "API" is it is an all-or-nothing proposition.
> 
> So by using the "older" update hook update-paranoid can make its
> decision on a per-ref basis and allow some refs to change in this
> push but abort/deny others.  I find that useful but not everyone
> might.
>  
> > AFAIK both update and pre-receive hooks are invoked also on fetch...
> > but I might be mistaken.
> 
> No, they are *not* invoked on fetch.  Currently no hooks execute
> during fetch; either on the server *or* on the client side of
> the connection.
> 
> -- 
> Shawn.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Bruno Ribas - ribas@c3sl.ufpr.br
http://web.inf.ufpr.br/ribas
C3SL: http://www.c3sl.ufpr.br 

Re: Git and securing a repository

[Gonzalo Garramuño]

Shawn O. Pearce wrote:
> 
> If you read the documentation carefully you will note that the
> pre-receive hook receives input on stdin; 1 line of data per ref
> that is being pushed with the old/new SHA-1 values and the ref
> name.  The hook exits 0 to allow all changes to take place and
> can exit > 0 to abort and disallow all updates.
> 

Sure, but I cannot pass any sort of authentication to the script other 
than rely on environment variables or system calls, as git will not 
provide anything else.

To do proper authentication on a file or directory basis, I have to mix 
two things then:

A user/group base authentication/login based likely on unix permissions 
and ssh AND a pre-receive hook script that finds the user/group name and 
then checks whether the user can change that particular file/directory.

I hope the ref name is the (relative) path name to the file and not just 
the file's basename.

If so, I can see that most of what I want to do is possible.  It is just 
pretty far from being elegant or easy to set up.

To distinguish a bad commit due to tabs for example from an actual 
permission trouble.  I'm assuming that the stderr/stdout of git hooks is 
redirected back to the client?

Even with all of that, it seems it is still not possible to limit pulls 
to a certain directory only, right?

Anyway, I think I more or less have the answer I (sadly) expected. 
Git's authorization mechanism is pretty much a roll your own type thing. 
  I'll check out the python authorization script that Linus mentioned to 
see if that alleviates setup troubles a bit.

-- 
Gonzalo Garramuño
ggarra@advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy

Re: Git and securing a repository

[Shawn O. Pearce]

Gonzalo Garramuo <ggarra@advancedsl.com.ar> wrote:
> Shawn O. Pearce wrote:
> >
> >If you read the documentation carefully you will note that the
> >pre-receive hook receives input on stdin; 1 line of data per ref
> >that is being pushed with the old/new SHA-1 values and the ref
> >name.  The hook exits 0 to allow all changes to take place and
> >can exit > 0 to abort and disallow all updates.
> >
> 
> Sure, but I cannot pass any sort of authentication to the script other 
> than rely on environment variables or system calls, as git will not 
> provide anything else.

Correct.
 
> To do proper authentication on a file or directory basis, I have to mix 
> two things then:
> 
> A user/group base authentication/login based likely on unix permissions 
> and ssh AND a pre-receive hook script that finds the user/group name and 
> then checks whether the user can change that particular file/directory.
> 
> I hope the ref name is the (relative) path name to the file and not just 
> the file's basename.

No, the ref name is the name of the branch being modified.  If there
is only one branch in your repository its probably always going to
be the default name of "refs/heads/master".

If you want to know what files the user has changed you need to
diff the two SHA-1s (old against new) to come up with the names of
the files being changed; e.g.:

	git diff-tree -r $old $new

The update-paranoid hook in contrib has support for doing this
built-in and can allow A/M/D type changes on specific file paths,
entire directories, or any regex pattern that matches the above.
I use this at day-job to prevent users from doing stupid things to
directories they shouldn't be changing on particular branches.

> To distinguish a bad commit due to tabs for example from an actual 
> permission trouble.  I'm assuming that the stderr/stdout of git hooks is 
> redirected back to the client?

You need to diff the old against the new (or use rev-list to list
all of the commits between old and new and then get the patch for
each of those commits) to determine if the commit is "bad" or not.
Remember that a single git-push can upload hundreds of commits in
one shot to the receiving repository.

But yes, both stdout and stderr of the hook are tied to the stderr
of the client running git-push.  So error messages produced by
the hook to explain why the push is being denied are visible to
the end-user who is executing git-push.  Again, update-paranoid
uses this to tell you if the "committer" line in commit objects is
invalid, or if you are changing a file you shouldn't be.
 
> Even with all of that, it seems it is still not possible to limit pulls 
> to a certain directory only, right?

No.  Git pretty much requires that when you have access to fetch/pull
a repository you have access to *all* of that repository.  Limiting to
a subdirectory would actually require moving that entire subdirectory
into its own repository and using git-submodule instead to manage it.

> Anyway, I think I more or less have the answer I (sadly) expected. 
> Git's authorization mechanism is pretty much a roll your own type thing. 
>  I'll check out the python authorization script that Linus mentioned to 
> see if that alleviates setup troubles a bit.

Its a distributed version control system.  All peers are equal.
Most security in Git is handled by only pulling from sources you
trust, and never allowing someone to push stuff into a repository
you own.

As such it also usually boils down to UNIX filesystem security; what
I let you see is what you can see, what I firewall and hide from
you is what you cannot see.  Quite simple when you think about it,
but then you are moving away from a centralized development model
and going to a distributed one... which is what Git was built for.

-- 
Shawn.

Re: Git and securing a repository

[Gonzalo Garramuño]

Shawn O. Pearce wrote:
> 
> Its a distributed version control system.  All peers are equal.
> Most security in Git is handled by only pulling from sources you
> trust, and never allowing someone to push stuff into a repository
> you own.
> 

Regarding that... is there a way to control the umask of a git clone 
independent of the actual umask of the user or directories inside the 
repository?  Ideally, on the server side?

That is, for sensitive repositories, I would like "git clone" to always 
clone that repository with 0700 permissions, so that the silly mistake 
of cloning a sensitive repository into a public directory and forgetting 
to restrict its permissions can be avoided completely.


-- 
Gonzalo Garramuño
ggarra@advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy

Re: Git and securing a repository

[Shawn O. Pearce]

Gonzalo Garramuo <ggarra@advancedsl.com.ar> wrote:
> Shawn O. Pearce wrote:
> >
> >Its a distributed version control system.  All peers are equal.
> >Most security in Git is handled by only pulling from sources you
> >trust, and never allowing someone to push stuff into a repository
> >you own.
> >
> 
> Regarding that... is there a way to control the umask of a git clone 
> independent of the actual umask of the user or directories inside the 
> repository?  Ideally, on the server side?
> 
> That is, for sensitive repositories, I would like "git clone" to always 
> clone that repository with 0700 permissions, so that the silly mistake 
> of cloning a sensitive repository into a public directory and forgetting 
> to restrict its permissions can be avoided completely.

No.

For a local clone (same UNIX system) you could probably easily
modify git-clone.sh to consult the config file of the source
repository to obtain recommended initial permissions, or just use
the source repository's directory permissions as the new clone's
initial permissions.  But not everyone would want that behavior.

For a remote clone (different systems) the config file of the source
repository isn't easily available.  So its not easily used to get
that setting.  The git protocol would have to be extended to make
transfer of parts of the config file possible.  We've talked about
this in the past but have never had a compelling application to
cause patches to be submitted for it.

-- 
Shawn.

Re: Git and securing a repository

[Jakub Narebski]

Shawn O. Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
  
> > AFAIK both update and pre-receive hooks are invoked also on fetch...
> > but I might be mistaken.
> 
> No, they are *not* invoked on fetch.  Currently no hooks execute
> during fetch; either on the server *or* on the client side of
> the connection.

Errr... I think at least post-update hook (the one with 
git-update-server-info by default) is invoked on fetch.

-- 
Jakub Narebski
Poland

Re: Git and securing a repository

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Shawn O. Pearce wrote:
>> Jakub Narebski <jnareb@gmail.com> wrote:
>   
>> > AFAIK both update and pre-receive hooks are invoked also on fetch...
>> > but I might be mistaken.
>> 
>> No, they are *not* invoked on fetch.  Currently no hooks execute
>> during fetch; either on the server *or* on the client side of
>> the connection.
>
> Errr... I think at least post-update hook (the one with 
> git-update-server-info by default) is invoked on fetch.

Please don't think then.  Instead check your facts before
posting to avoid wasting bandwidth and people's time.  The
post-update hook is run on the remote end when you push into it.

I do not particularly like hooks that act after an operation is
initiated locally and act solely on local data.  This is maybe
because I still consider git tools building blocks suitable for
higher level scripting more than other people do.

There are five valid reasons you might want a hook to a git
operation:

 (1) A hook that countermands the normal decision made by the
     underlying command.  Examples of this class are the update
     hook and the pre-commit hook.

 (2) A hook that operates on data generated after the command
     starts to run.  The ability to munge the commit log message
     by the commit-msg hook is an example.

 (3) A hook that operates on the remote end of the connection
     that you may not otherwise have access to other than over
     the git protocol.  An example is the post-update hook.

 (4) A hook that runs under a lock that is acquired by the
     command for mutual exclusion.  Currently there is no
     example, but if we allowed the update hook to modify the
     commit that was pushed through send-pack => receive-pack
     pair, which was discussed on the list a while ago, it would
     be a good example of this.

 (5) A hook that is run differently depending on the outcome of
     the command.  The post-merge hook conditionally run by
     git-pull is an example of this (it is not even run if no
     merge takes place).  Another example is the post-checkout
     hook that gets information that is otherwise harder to get
     (namely, if it was a branch checkout or file checkout --
     you can figure it out by examining the command line but
     that already is part of the processing git-checkout does
     anyway, so no need to force duplicating that code in the
     userland).

You cannot do an equivalent operation from outside the git
command for the above classes of operations.  You need hooks
for them.

On the other hand, if you want to always cause an action after
running a git opeation locally, you do not have to have a hook.
You can just run them yourself, or have "git myfetch" wrapper
that does whatever you want after running "git fetch".  Only
when the combination of the underlying command and something
else is widely useful, _and_ that something else needs
flexibility, a hook is warranted (if that something else is
always the same thing, it is better to fold that into the
underlying command).

Re: Git and securing a repository

[Jan Hudec]

On Wed, Jan 02, 2008 at 07:04:09 -0300, Gonzalo Garramuño wrote:
> Felipe Balbi wrote:
>>
>> it's easy on the full repository case, create different groups and
>> share git repositories by groups, after that chmod o-rwx -R
>> /path/to/repository.git.
>>
>
> Thanks.  I'll admit what you describe is somewhat discouraging, as what you 
> are just describing is just managing user accounts or groups on the 
> underlying OS.  That does not extend well to placing code on the net and 
> has a bunch of administrative headaches.
>
> I was really looking for a permission based system that was part of git 
> itself (and thus more portable and easier to admin), and not the OS. 
> Something akin to what perforce or even CVS can do.

You don't need to manage user accounts -- managing ssh public keys will do!

The git ssh access will always run one particular command (with path as
argument) to push and another particular command (again with path as
argument) to pull.

Thus you can prepare two scripts -- git-read-only will only run
$SSH_ORIGINAL_COMMAND if it is 'git-upload-pack <somearg>' and git-read-write
will also run it if it is 'git-receive-pack <somearg>'. The <somearg> is path
to the repository, so you can further limit on that. (Note: for recent git,
you need to recognize the 'git upload-pack' and 'git receive-pack' variants
too).

Now you can have each user create a ssh public key. You will put this key
into the .ssh/authorized_keys file on the server (therefore you only need
a single account there), with option command= specifying appropriate script
depending on what permissions the user should have. Than that user will be
able to push/pull (as set) via ssh using that public key and will not have
any other access to the server.

As a bonus, this way the users can't circumvent the pre-receive hooks
(perhaps you will allow each user to only push to a particular branch or
something) by manually changing the repository.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

Re: Git and securing a repository

[Gregory Jefferis]

On 2/1/08 19:31, "Jan Hudec" <bulb@ucw.cz> wrote:

> 
> You don't need to manage user accounts -- managing ssh public keys will do!

Has anyone used gitosis?

http://eagain.net/gitweb/?p=gitosis.git

http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-w
ay

It seems to make setting up this kind of approach easier.

Best,

Greg.

-- 
Gregory Jefferis, PhD                               and:
Research Fellow
Department of Zoology                               St John's College
Downing Street                                      Cambridge
Cambridge, CB2 3EJ                                  CB2 1TP 

Re: Git and securing a repository

[Linus Torvalds]

On Wed, 2 Jan 2008, Gonzalo Garramu?o wrote:
> 
> I was really looking for a permission based system that was part of git itself
> (and thus more portable and easier to admin), and not the OS. Something akin
> to what perforce or even CVS can do.

Well, git by design doesn't do that. 

That doesn't mean that it has to be OS-level permissions (in fact, it 
generally shouldn't), it just means that git wasn't really meant to care 
about permissions itself, and you the user management and permissions 
should come from "outside".

That outside *can* be OS-level things like just permissions on files, but 
more commonly it's things like SSH keys and using the git hooks. In other 
words, pretty much by design, git is meant to be the *core* SCM 
infrastructure, and then you layer your user management on top of it as a 
*separate* layer.

An example of that would probably be gitosis, but I haven't used it 
myself. For the kernel, people literally tend to just use SSH accounts, 
and not any central repository at all (ie the kind of crazy "central repo 
access control rules" that centralized repos need are just not necessary 
at all in a more distributed usage model).

See 

	http://eagain.net/gitweb/?p=gitosis.git
	http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way

for a quick starting point on gitosis, if that suits your needs (there's 
more, google is your friend).

			Linus

Re: Git and securing a repository

[Daniel Barkalow]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2124 bytes --]

On Wed, 2 Jan 2008, Gonzalo Garramuño wrote:

> I've been using git for some time and love it.  For open source projects
> there's clearly nothing currently better.
> 
> However, I am now using git for proprietary elements, which in the future I
> may need or want to partially restrict access to.  The idea being that at my
> company some (junior) developers should not be given access to some elements.
> That means either that some full git repository should be password protected
> or even portions of the same repository.
> 
> Another desirable way to protect elements might be only giving clone/pull
> access to a repository (or portion of it) but not permissions to push in
> changes.

In order to understand the security model, you have to remember that git 
is designed as a distributed system. Authorization is fundamentally not at 
a project level, but rather at a repository level, and clones are all 
different repositories. This makes portability of the mechanism less 
important, because a particular set of authorization rules only applies to 
a particular repository, which is going to be on some single system.

For that matter, git doesn't run with any special privileges in general; 
if a user can affect the repository with git operations, that user can 
affect the repository by hand, so git-specific rules aren't helpful. 
(Although I suppose it would be theoretically useful to make git-shell, 
the shell that only runs git programs, able to apply restrictions, since 
it is used in a context where the user doesn't have any other access to 
the filesystem.)

For read access restrictions, you want to use submodules (or entirely 
separate projects); git is fundamentally unhappy running with less than 
all of the project accessible, except for when a project references 
another project with submodules. And, of course, if the code base is such 
that users can do useful work without any access to some of the files, 
those files must be optional and somewhat separate from the necessary 
portions, and it makes sense to handle them separately anyway.

	-Daniel
*This .sig left intentionally blank*