Some points that seem to be necessary (though I freely admit that I am not expert in these matters), and that were not covered in RobertL's otherwise admirably thorough answer.
- Make sure that the other users have actually logged into group
admin:
A$ newgrp admin
Since the users are already in the group, I think you will not need to set a group password. If you do:
A$ sudo chgpasswd
admin:secret (typed into stdin)
- Make sure that D's home directory is in group
admin and is group-searchable.
D$ chgrp admin ~
D$ chmod g+x ~
D$ ls -lad ~
drwx--x--- 3 D admin 4096 Nov 24 19:25 /home/D
The directory needs to be searchable to allow users to enter it or its subdirectory project. It doesn't need to be group-readable, so D's own filenames are still private. To let the other users get to project easily, have them create symbolic links to it; otherwise, they'll have to type the whole path each time (autocomplete won't work because the shell can't read the pathname, it can only go to it).
If you have a ssh agent running, do:
sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" git clone...
That basically tells the git command started by root (or the ssh command started by that git command) to use your ssh agent (how to connect to it, which root should be able to as it has every right).
If you don't have a ssh agent running, you can start one beforehand with:
eval "$(ssh-agent)"
(and add keys to it as needed with ssh-add).
Alternatively, you can use
sudo -E git clone...
To pass every environment variable across sudo, not just $SSH_AUTH_SOCK.
I would not got with @NgOon-Ee's suggestion in comment to add $SSH_AUTH_SOCK to the env_keep list. In general, you don't want to pollute root's environment, as that's the user you start services as. For instance sudo sshd to start a sshd service would mean all ssh sessions started through that service would inherit your $SSH_AUTH_SOCK, polluting users environment with something they can't and shouldn't use. Even for other target users than root, passing that variable across would not make sense as the target user couldn't make use of that authentication agent.
Now, that only addresses key authentication. If you also wanted root to inherit your settings in your ~/.ssh/config, you could not do that with ssh environment variables, but you could do that with git environment variables. For instance, defining a sugit function as:
sugit() {
sudo "GIT_SSH_COMMAND=
exec ssh -o IdentityAgent='$SSH_AUTH_SOCK' \
-o User=$LOGNAME \
-F ~$LOGNAME/.ssh/config" git "$@"
}
That is, tell git to use a ssh command that uses your ssh config file and agent and username instead of root's.
Or maybe even better, tell git to run ssh as the original user:
sugit() {
sudo "GIT_SSH_COMMAND=
exec sudo -Hu $LOGNAME SSH_AUTH_SOCK='$SSH_AUTH_SOCK' ssh" git "$@"
}
Best Answer
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.