File permissions when removing user from git

Question

I have a shared git repository set up, which users pull from with the ssh protocol.

I would like to set up the permissions in a way that only users in a specific user group (e.g. git_group) may access the repository. I can make created files accessible by this group, either by using:

• Setgid: chmod g+s. Recursively: find . -type d print0 | xargs -0 chmod g+s.
• Set defaults in the access control lists.
  • sudo setfacl -R -m g:git_group:rwx . and
  • sudo setfacl -R -d -m g:git_group:rwx .

This all seems fine until you remove a user from git_group. When that user pushed commits, they became owner of some files in the git repository. After being removed from the group, that user may still modify those files, and some git commands may still succeed.

---

Changing the owner of all files in the git repository would deny the user access to the repository, but is it possible to set up the repository so that users are denied access simply by removing them from the group?

As far as I know, with basic linux file permissions, the group being given more permission than the owner leads to undefined behaviour.

Answer 1

Expanding on vorac's commnt, fined grained permissions is one of the main reasons to use dedicated git server software.

Relying on linux's file system permissions just doesn't work for anything except read-only permission. As you've discovered, when other user's modify the repository they own files they've uploaded and have completely control of the permissions on those files so can actually be quite distructive with it.

The only way around this is to force users to access via dedicated git server software. This can still allow users to access via the ssh protocol but they do so either by a completely customised SSH server or, in the case of gitolite, a very customised SSH user.

For very simple light weight setup gitolite is good enough. Over time you may find yourself wanting to migrate to more complext ERM tools like gitlab.