Git and securing a repository

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?

On Jan 2, 2008 2:13 AM, Gonzalo Garramuño <ggarra@advancedsl.com.ar> wrote:

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

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.

Felipe Balbi wrote:

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.

On Jan 2, 2008 9:04 PM, Gonzalo Garramuño <ggarra@advancedsl.com.ar> wrote:

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

Dave.

David Symonds wrote:

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> writes:

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 <jnareb@gmail.com> 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.

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

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.
 

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.
 

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.

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:

Shawn O. Pearce wrote:

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 Garramuo <ggarra@advancedsl.com.ar> wrote:

Correct.
 

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.

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.
 

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.

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 O. Pearce wrote:

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 Garramuo <ggarra@advancedsl.com.ar> wrote:

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 O. Pearce wrote:

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

Jakub Narebski <jnareb@gmail.com> writes:

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).

On Wed, Jan 02, 2008 at 07:04:09 -0300, Gonzalo Garramuño wrote:

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.

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

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.

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

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

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

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*