Git pull via SSH command changes folder permissions
I made a script for automatic deployment, it does the following:
ssh [email protected] "cd domains/domain.com && git reset --hard && git pull --no-rebase"
For some reason, it messes up the folder permissions of the css folder. If I run this command, the permissions are set to 700, instead of 755, which it should be.
However, when first login to SSH by hand, and then execute the commands there:
ssh [email protected]
cd domains/domain.com
git reset --hard
git pull --no-rebase
The folder permissions are correct!
It's worth noting that this bug seems to have introduced itself when the server was updated to git version 2.27.0
Why is this?
Generally, git lets the OS decide file permissions (except for +x, which Git tracks) – whether new files are world-readable usually depends on the umask that is set for the current process.
When you log in, the umask can be set at several places:
- Some initial umask inherited from sshd.
- A distribution default umask set through /etc/login.defs.
- Set by PAM (pam_umask).
- Set by your ~/.bashrc or ~/.profile running the
umaskshell builtin.
However, when you run SSH in "batch mode" – specifically, when the SSH server runs your shell in "batch mode" – step #3 is usually skipped, so the umask set by PAM will remain and the one in ~/.profile will not be set at all.
So first compare the result of running umask over SSH interactively, with the result of running ssh user@host "umask" to see if they're different. (The result you want is "0022", as it indicates which bits should be removed.)
It is also possible to set default permissions per directory, using default ACLs – run getfacl on the directory to see those. Look for items like default:user::.
There's only one somewhat relevant git setting – core.sharedRepository, but it only really affects the permissions of Git internal files (i.e. stuff in the .git/ directory) – it doesn't alter the permissions of regular working-tree files.