2

From my local git, I push to my private remote repo (via ssh), where I would like all files to be stored without any permissions for group, and in particular without access for others.

I have attempted to help myself by setting an git internal umask overwrite in the configs of the remote git

the relevant setting in remotes .git/config

[core]
    sharedRepository 0600

which I thought to mean. "Hey git whenever you do a checkout, would you be so kind and set 6 (rw permissions to the file owner), and 0 (no permissions at all to group and others).

The version of git used on the remote side is 2.7.4.

This did however not work out. Several times I pushed new files to the remote (non-bare) git repo, which when eventually checked out there, are checked out with world readability set.

Other attempt
Additionally I thought that I could set the umask in the pre-receive hook script.

.git/hooks/pre-receive content is 

#!/bin/bash

umask > /umask.at.pre-receive
umask 0077
exit 0

the script gets successfully executed upon push, however the desired effect that all files written (including the objects, the .git folder content etc) would be have permissions uset for (group and others).

update

Some answer (which has in the meantime been removed) implied (to my understanding), that the problem might be that core.sharedRepository setting does only work locally. Consequently when working remotely a call o git push, will not trigger the remote side to use the settings of core.sharedRepository.

Also the answer suggested to look into smudge-filters, as those would allow to change the files before they are checked out. Maybe this can be a partial solution to the problem depicted in this question.

humanityANDpeace
  • 4,350
  • 3
  • 37
  • 63
  • I removed my answer about smudge filters, because I discovered, that this way you cannot change file mode (only file content). I am a little baffled by this and I am looking for a solution right now, but wouldn't be surprised if such functionality was missing from Git at the moment. – Patryk Obara Nov 27 '17 at 13:55
  • @PatrykObara I appreciated the answer anyway. It made the point that the reason why `core.sharedRepository` might be a "dead-end" is because this setting applies only to filesystem local permissions. – humanityANDpeace Nov 27 '17 at 13:59

1 Answers1

1

Some band-aid, workaround "solution" to have remote git set file permissions to owner r,w only I have come up with, to somewhat mitigate/solve the problem that motivated my question is.

on the remote .git/hooks/post-receive I put

#!/bin/bash

# change recursively the file permission of the parent dir (cwd was .git)
# to owner access only
chmod o-rwx,g-rwx .. -R

exit 0

Talking about permissions, here the shortcoming of this solution is that there is a time in which the files have been brievly accessible to group, others.

I hope somebody hence might provide a more reliable answer, which not re-adjust file permissions, but makes git create files with the correct limited permissions right from the start.

update

When creating files git does (at least what showed several tests I did) respect the umask (assuming of course the OS supports umask provision via systemcall). The very easy solution hence is to set the umask for the remote git. Such is often done via the .profile or sometimes the standard shell init rc files (e.g. .bashrc) which seems to get executed upon each ssh, including the during invoking the remote git. Hence setting

remote machines .bashrc with this line

umask 0077

did eventually lead to remote git creating files with the desired (reduced) permission set.

humanityANDpeace
  • 4,350
  • 3
  • 37
  • 63
  • The only permission bit that Git stores is "executable vs not executable". All file blobs are either `mode 0755` or `mode 0644`. It's up to the *process running Git* to control group and other permissions for files created in the work-tree: Git actually tries to create them as mode 0777 or mode 0666, and relies on the current `umask` to remove unwanted group and other permissions. – torek Nov 27 '17 at 14:55
  • @torek I know that git does not track permissions, with exception if a file is executable. The question answered here was anyway not about if `git` tracks it but if git hat a switch to *override* provided `umask` (such as in cases where prior setting of `umask` is impossible). Your comment provides further info to the answer, which is great :) – humanityANDpeace Nov 27 '17 at 16:14