Question

The Issue: when multiple users have access to the same working directory, permissions issues can occur in the meta-data if any git operations are performed.

DISCLAIMER: Before you chastise me – I realize sharing a working dir is counter to what Git stands for, and I am not talking about doing anything other than read-only operations in this shared directory – we do all our work in our own local repositories.

I’m open to suggestions as to another way to do what we are trying to do, as our approach is certainly not best practice, but I’m not sure that conversation that would be useful for others to listen to. So for now let me provide some details on why we are doing this:

We have several build-masters on our team. We deploy to Linux servers, and we do our builds there, with build scripts that pull directly from Git. We are not able to use CI (such as Jenkins/cruisecontrol) at this time, so we have a repository that we checkout and do our QA builds from.

There are some git operations that we perform as part of the script. This includes some tagging of commits (stuff gets tagged as QA-current, QA-previous, etc…). So I guess we aren’t actually read-only entirely. Due to the nature of the build script, we run it sudo‘ed as a common user (let’s call that user DevAdmin). I realize this might be a bad practice, and is perhaps the source of the pain, since it forces us to use a shared repo checkout.

This would all be fine, if we were always sudo’ed when in that working dir. The issue is that on occasion, one of us will do a git pull or something similar by accident, without being sudo’ed as DevAdmin. So most of the files in .git are owned by DevAdmin (who performed the initial clone), but whenever we do this, we end up with dir’s in .git/objects that contain files owned by a specific user. And these are created as group-unwritable. I’ve also noticed ORIG_HEAD with wrong ownership, for example. So when we try to do something as DevAdmin, we get issues.

Is there anything that we can do to fix this issue? Right now, we have to recognize that it has happened, and then get a server admin to chown .git back to DevAdmin. Or have the user delete the meta-files in question, or at least chmod them to group-writable. This all seems very bad.

I’ve considered a couple of options that don’t involve changing our build and maintenance processes dramatically:

If we removed group-write access on .git and restricted it to DevAdmin, would that prevent this from happening again? This seems the most straightforward option.

Or is there a way to make everything in .git group-writable, even when it’s newly created? This seems like asking from trouble.

Is there something else obvious I’m missing? I realize that the best thing would probably be to change our process so that users could work in their own repo’s, but in a business setting, the repos can get very large (jars aren’t separated out yet, lots of binary files, etc…), and we can’t have multi-GB repos for everyone’s account. Additionally, our system administrators would have a lot of work ahead of them changing their processes to allow for it.

Any thoughts are appreciated.

Answer 1

There are a number of ways to address this problem. Personally, I’d recommend the following in your existing repository:

# Create a group named "gitshare" that will share the repository.
sudo groupadd gitshare

# Add yourself and as many others as you want to the group.
sudo adduser "$LOGNAME" gitshare

# Everything else needs to run from the top level of your Git repository.
cd /path/to/repository

# Add group permissions for *new* modifications to repository.
git init --shared=group

# Fix permissions for existing repository objects.
chown -R :gitshare "$PWD"
chmod -R g+swX "$PWD" 

Obviously, you need to make sure that the users have directory traversal permissions all the way to your repository (e.g. user-private directories may cause problems), and that all team members who need access belong to the repository’s shared group. After this initial setup, though, it should “just work.”