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?
Best Answer
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:
umask
shell 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 runningssh 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 likedefault: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.