Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a Git repository on a staging server which multiple developers need to be able to pull to. git-init seems to have a flag very close to what I'm looking for: --shared, except I'd like multiple people to pull to that repository, as well. The git-clone's --shared flag does something entirely different.

What's the easiest way to change an existing repository's permissions?

share|improve this question
add comment

7 Answers

up vote 63 down vote accepted

Permissions are a pest.

Basically, you need to make sure that all of those developers can write to everything in the git repo.

Skip down to The New-Wave Solution for the superior method of granting a group of developers write capability.

The Standard Solution

If you put all the developers in a specially-created group, you can, in principle, just do:

chgrp -R <whatever group> gitrepo
chmod -R g+swX gitrepo

Then change the umask for the users to 002, so that new files get created with group-writable permissions.

The problems with this are legion; if you’re on a distro that assumes a umask of 022 (such as having a common users group that includes everyone by default), this can open up security problems elsewhere. And sooner or later, something is going to screw up your carefully crafted permissions scheme, putting the repo out of action until you get root access and fix it up (i.e., re-running the above commands).

The New-Wave Solution

A superior solution—though less well understood, and which requires a bit more OS/tool support—is to use POSIX extended attributes. I’ve only come to this area fairly recently, so my knowledge here isn’t as hot as it could be. But basically, an extended ACL is the ability to set permissions on more than just the 3 default slots (user/group/other).

So once again, create your group, then run:

setfacl -R -m g:<whatever group>:rwX gitrepo
find gitrepo -type d | xargs setfacl -R -m d:g:<whatever group>:rwX

This sets up the extended ACL for the group so that the group members can read/write/access whatever files are already there (the first line); then, also tell all existing directories that new files should have this same ACL applied (the second line).

Hope that gets you on your way.

share|improve this answer
23  
git init has a parameter called --shared which sets up the core.sharedRepository variable for group work. You can also set the variable on an existing repository. That removes the need of manually setting the umask as git will set it to a sane value before manipulating files. –  ptman Feb 17 '10 at 9:04
2  
+1 for POSIX extended attributes - news to me! –  RobM Nov 2 '11 at 15:08
3  
When I did chmod -R g+swX, it made Git very unhappy and it decided it wasn't a git repository anymore ("repo does not appear to be a git repository"). I had to chmod g-s all of the files. To just set the setgid bit on the directories, try find /path/to/repo -type d -print0 | xargs -0 chmod g+s. Still do the chgrp -R thegroup /path/to/repo. –  rescdsk Apr 25 '12 at 19:01
4  
chmod -R g+swX gitrepo will apply the setguid bit to files, which is a security risk. Instead, you can use find . -type d -exec chmod g+s {} + to apply it only to directories. –  Ian Dunn Sep 19 '12 at 19:47
    
ACL (setfacl) doesn't have setting for setgid to enforce new files and subdirectories created within a directory to inherit its group ID. Therefore, you must set setgid separately through chmod. Git's --shared option (git-scm.com/docs/git-init), however, allows you to setgid and override the umask of the user. –  Chase T. Apr 9 at 15:17
add comment

if you created the repository (or cloned a new bare repo off an existing one) with

$ git init --shared=group 

or

$ git init --shared=0NNN

Git is supposed to handle permissions above and beyond what your default umask provides. At last this is true on my version of Git (1.6.3). Of course this assumes your users are in the same group.

If I needed management of users in multiple groups with varying degrees of read/write however, I'd go with gitosis. I have also heard mention of gitolite (http://github.com/sitaramc/gitolite), a gitosis fork that is suppossed to provide branch level permissions, can't say I've every used it personally though.

share|improve this answer
    
This is definitely the correct answer. –  elliottcable Dec 5 '11 at 7:45
3  
I had this issue and this is by far the best answer. The only problem is that the --shared argument takes in an octal, not hexadecimal. I have confirmed this in the source of Git 1.7.8 and the second example should be git init --shared=0NNN. –  qpingu Jan 25 '12 at 5:42
add comment

This has not been said, so I want to quickly add it.

To ensure that permissions issues do not crop their ugly head, make sure to set the following on your git shared repository's config file:

[core]
    sharedRepository = true

This will ensure that your system's "umask" settings are respected.

share|improve this answer
2  
According to git-config(1) (kernel.org/pub/software/scm/git/docs/git-config.html) core.sharedRepository, you need to set this to "umask" or "false" to have git respect the user's umask. –  David Schmitt Aug 12 '11 at 10:05
6  
This and user35117's answer is correct. Note that "true" is the same as "group", and this can be set with the command git config core.sharedRepository true. –  ColinM Dec 22 '11 at 3:43
add comment

The Git User Manual describes how to share a repository in several ways.

More complicated, though feature-full ways to share repositories are:

We use GitHub for a team of 6 developers.

share|improve this answer
    
I like Gitosis. It's a pretty effective way to control access based on public keys. –  Mike Mazur Jun 17 '09 at 7:42
    
How do any of these solutions solve the problem of "I'd like multiple people to pull to that repository"? –  womble Jun 17 '09 at 7:59
    
have a look at gitosis. that one solves your problem. –  pilif Jun 17 '09 at 8:43
2  
When you share the repository, people will be able to pull from it. They'll likely need to clone it, or add a remote branch. The documentation I linked will very clearly walk you through solving your issue; I've used all the methods described to help developers collaborate source code with Git. To my knowledge ServerFault isn't for handholding. –  jtimberman Jun 17 '09 at 17:34
2  
I have to agree with using Gitosis. It gets around the permissions issue by using a single account authenticated by multiple SSH keys. It is also managed entirely itself via git commits. –  Jeremy Bouse Jun 18 '09 at 18:42
show 2 more comments

Also look at gitolite for hosting your git repository. Gitosis apparently isn't being developed anymore.

share|improve this answer
add comment

One way to fix permissions in the shared repository, so users won't have permission problems when pushing, is to create a post-update hook script which will do just that. This should work in any git version.

Suppose you have a shared repository in /myrepo.git. All files in that repository belong to say mysharedgroup. All users pushing to that repository should belong to mysharedgroup also. Now create the following file (changing mysharedgroup to your preferences):

/myrepo.git/hooks/post-update

#!/bin/sh
chmod -R g+w . 2>/dev/null
chgrp -R mysharedgroup . 2>/dev/null
share|improve this answer
    
the right answer for when users have different default groups –  Pat Nov 23 '11 at 23:42
    
Setting the setgid bit on a directory will cause files that users create to inherit the same group ownership as the directory (if the users belong to that group). Even if it's not the users' default group. Then this hook is not needed. This is what @womble's answer (and my comment on it) do. –  rescdsk Apr 25 '12 at 22:21
add comment

You can use git-daemon to share the repository. Read the documentation for git-daemon for more information.

EDIT:

Also check this article 8 ways to share your git repository.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.