I have restored a git repo from backup and it does not have the correct file permissions. Is it enough to set owner +rw on all files and directories in .git, or is it more subtle?
Is there a utility to check or reset .git file permissions?
Asked
Active
Viewed 6,296 times
2 Answers
35
Directories should have 755 permission; files should have 644 permission.
That's a pretty good rule of thumb unless you expect members of your group to make changes to your repository.
Having said that, in one of my repositories, the files under .git/objects/* have 444 (readonly) permission for everyone. Other files are 644 as suggested.
This script, run in the top-level directory just above the .git repository would fix the permissions:
find .git -type d | xargs chmod 755
find .git/objects -type f | xargs chmod 444
find .git -type f | grep -v /objects/ | xargs chmod 644
I started with -print0 for the first two find commands and xargs -0 to allow for the remote possibility of spaces in file names. But the grep -v in the third command would be difficult to manage with the -print0 format - so I omitted the space-safe notation from all the commands, knowing that git does not create files with spacing in names under the .git directory.
Jonathan Leffler
- 730,956
- 141
- 904
- 1,278
-
I had a .git/FETCH_HEAD permission denied message when I ran ```git pull``` no matter what permissions I set on it. This solved the problem and helped me set group permissions. Thanks! – Ben Zuill-Smith Nov 05 '13 at 04:08
-
What is the minimal though. Can't we go 750 on the dirs, and 440/640 on the objs? Assuming the env is properly setup, with groups. – blamb Jan 31 '17 at 00:14
-
@blamb: The minimum depends on what you want who to be able to do. It also depends in part on whether you're going to use ACLs (access control lists) to help manage who can do what. You might get away with 700 permissions; only the user can access the directory. There is no 'universally correct' answer — there are options depending on your requirements. – Jonathan Leffler Jan 31 '17 at 00:17
-
@JonathanLeffler ok yeah so i normally dev on a box, then push to prod machine, and i dont like to filemode false, so the security on prod starts on dev. (plus im a one man show, with visions of team collab accessl, shared-hosting in this case, so basic access, you know how apache runs there normally) lets go with that. NO ACLS, since this is a perms method. advice? By the way, no probs with my initial recommendation yet (750/440/640), i tested it. – blamb Jan 31 '17 at 01:22
1
In addition to @Jonathan Leffler's answer, it's worth to mention the ownership of the .git and its parent directories, too. For example:
sudo chown -v "$( id -u; ):$( id -g; )" .;
sudo chown -v "$( id -u; ):$( id -g; )" -R .git;
find '.git' -type d -exec chmod -v 775 {} \;;
find '.git/objects' -type f -exec chmod -v 444 {} \;;
find '.git/hooks' -mindepth 1 -maxdepth 1 -type f -exec chmod -v 775 {} \;;
find '.git' -type f ! -path '.git/objects/*' ! -path '.git/hooks/*' -exec chmod -v 664 {} \;;
Related:
ensure_valid_ownership()
https://stackoverflow.com/a/74209644/5113030 (git submodule update failed with 'fatal: detected dubious ownership in repository at'...)
