5

After pushing files to our server, the following post-receive hook is executed:

#!/bin/sh
export GIT_WORK_TREE=/home/user/www/
git checkout -f

However, files get a very odd 600 permission, and folders 700 upon checkout. This is not what I expect (on our other servers we get 644 and 755). From this thread I understand that git does not set permissions, so git is not to blame. My question is: what is? How can I figure out what the cause is of this issue?

I have already temporarily solved it by running an extra script upon checkout to fix the permissions, but I am interested in solving the root cause.

I'm using gitolite to manage the repositories, but I doubt that is the cause. But again, I'm happy to learn where I can start because at this point I'm not sure how to investigate this.

As per the initial answers I have looked into the umask settings on the server. The git user (that's the user used to upload the files), the umask setting is 0002. This is confirmed in the following exercise:

git@server:~$ umask
0002
git@server:~$ touch newfile
git@server:~$ ls -la newfile
-rw-rw-r-- 1 git git 0 Aug  5 10:46 newfile

Additional details:

  • Linux used on both server side and development side
  • In the local repo, permissions are 755 and 644
  • filemode is set to true in .git/config
user32421
  • 689
  • 3
  • 8
  • 19
  • Read this out: http://stackoverflow.com/questions/2517339/how-to-recover-the-file-permissions-to-what-git-thinks-the-file-should-be – CodeWizard Aug 05 '16 at 12:33
  • Thanks @CodeWizard. But git supposedly only tracks executable bits, so it can't be git that causes read/write permissions to go missing in action, right? – user32421 Aug 05 '16 at 12:42

2 Answers2

3

As in "Git change default umask when update file", can you add umask to your hook?

#!/bin/sh
umask 002
export GIT_WORK_TREE=/home/user/www/
git checkout -f

That should set file permissions to 664 and directory permissions to 775.

Regarding gitolite specifically, check the umask section of the gitolite.rc file:

$UMASK, octal, default 0077

The default UMASK that gitolite uses gives rwx------ permissions to all the repos and their contents.
People who want to run gitweb (or cgit, redmine, etc) realize that this will not do.

The correct way to deal with this is to give this variable a value like 0027 (note the syntax: the leading 0 is required), and then make the user running the webserver (apache, www-data, whatever) a member of the 'git' group.

If you've already installed gitolite then existing files will have to be fixed up manually (for a umask or 0027, that would be chmod -R g+rX). This is because umask only affects permissions on newly created files, not existing ones.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks @VonC but this is merely a fix of the symptom rather than the problem, right? I already added some extra post-receive code to fix the permissions, but my question is: how can I find out what program/setting is responsible for the change in permissions? After all, it's not normal for files to be uploaded as 600 isn't it? – user32421 Aug 05 '16 at 12:44
  • @user32421 this is not a fix of the symptom but the actual solution. This is linked to the linux profile running that hook: http://www.cyberciti.biz/tips/understanding-linux-unix-umask-value-usage.html. By adding umask in the hook, you no longer depend on that profile setting. – VonC Aug 05 '16 at 12:59
  • @user32421 This is Linux-related (where user file-creation mode mask (umask) is use to determine the file permission for newly created files), not git related. – VonC Aug 05 '16 at 13:00
  • Thanks @VonC but if it the problem was related to the umask setting then I'd rather change this in the profile setting, rather than for every repository. But as mentioned in the updated post, the problem doesn't seem to be with the umask setting. – user32421 Aug 05 '16 at 14:49
  • @user32421 changing it in the profile means you are dependent on the execution environment. Setting it in the hook means the hook will do the right thing, independently of the profile. – VonC Aug 05 '16 at 14:51
  • @user32421 Did you try it (ie setting the umask *in* the hook itself), to validate if the files are created with the right permission? – VonC Aug 05 '16 at 14:52
  • Thanks, but I'm looking for a way to solve it for any new repository, without depending on a new hook. I did try changing the umask setting in the hook and that does work, but I am looking for a way to change my umask setting on my system, not in any repository. Let me open a new question about that. Thanks for your help. – user32421 Aug 06 '16 at 06:08
2

However, files get a very odd 600 permission, and folders 700 upon checkout.

It looks like your shell has a restrictive umask setting, possibly umask 0177.

From this thread I understand that git does not set permissions, so git is not to blame.

No, it is the umask setting of your shell.

My question is: [...] [how] can I figure out what the cause is of this issue?

Run umask, it will tell you what is your current setting. It's like to be 0177 or similar. If you want to know why, you need to look through the rc files used by /bin/sh, most probably .profile or .bashrc, and other files sourced.

You can have very restrictive umask settings but override them in your script, by adding a umask line as @VonC suggested.

janos
  • 120,954
  • 29
  • 226
  • 236
  • Thanks, that indeed seemed to be the case but I checked this and the git user has umask '0002', so this still doesn't explain it. I tried running 'touch newfile' as the git user and it got the normal permissions. Will update my answer to add these insights. Any other ideas? – user32421 Aug 05 '16 at 14:45
  • Put those commands in your post-receive hook, for example `umask > /tmp/debug.log` and test it, and see the content of `/tmp/debug.log` as well as the permissions of that file. The umask settings in your interactive shell may very well be different from the settings effective in the post-receive hook – janos Aug 05 '16 at 14:58
  • Thanks, that exercise indeed shows that the umask of my interactive shell is indeed different than the umask of the user that logs in. I am not sure why that is the case. Let me open a new question about this as not to have all this info in the comments. Technically you answered my question fully, as to how I could figure out where the problem lies, so this one is closed. Thanks! – user32421 Aug 06 '16 at 06:06
  • To find out *why*, look through the rc files used by `/bin/sh`, most probably `.bashrc` and others it sources. – janos Aug 06 '16 at 06:13
  • I set the ~/.bashrc to have a umask of 0002... but still not working. See more explanations here: https://stackoverflow.com/questions/38801251/what-causes-gits-post-receive-umask-to-be-different-from-the-users-umask – user32421 Aug 06 '16 at 06:28