Permissions are a pest.
Basically, you need to make sure that all of those developers can write to everything in the git repo.
Skip down to The New-Wave Solution for the superior method of granting a group of developers write capability.
The Standard Solution
If you put all the developers in a specially-created group, you can, in principle, just do:
chgrp -R <whatever group> gitrepo
chmod -R g+swX gitrepo
Then change the umask
for the users to 002
, so that new files get created with group-writable permissions.
The problems with this are legion; if you’re on a distro that assumes a umask
of 022
(such as having a common users
group that includes everyone by default), this can open up security problems elsewhere. And sooner or later, something is going to screw up your carefully crafted permissions scheme, putting the repo out of action until you get root
access and fix it up (i.e., re-running the above commands).
The New-Wave Solution
A superior solution—though less well understood, and which requires a bit more OS/tool support—is to use POSIX extended attributes. I’ve only come to this area fairly recently, so my knowledge here isn’t as hot as it could be. But basically, an extended ACL is the ability to set permissions on more than just the 3 default slots (user/group/other).
So once again, create your group, then run:
setfacl -R -m g:<whatever group>:rwX gitrepo
find gitrepo -type d | xargs setfacl -R -m d:g:<whatever group>:rwX
This sets up the extended ACL for the group so that the group members can read/write/access whatever files are already there (the first line); then, also tell all existing directories that new files should have this same ACL applied (the second line).
Hope that gets you on your way.
As requested, a bit of a tutorial on groups. Hopefully this isn't too elementary.
By default, most user accounts are also part of a group of the same name. To determine what groups an account is a member of, use the groups command.
# groups root
root : root bin daemon sys adm disk wheel
The first one listed is the primary group, and will be the default group owner of any files that user creates. That's listed in the output of ls as the second 'root' entry.
# touch testfile
# ls -l testfile
-rw-r--r-- 1 root root 19 Jan 29 08:37 testfile
In order to add a user to a group, you use usermod as shown. The lowercase "-g" flag you gave it changes the primary group. It may be better to change just a secondary one, using the "-G" and "-a" flag. Namely, to put the git user into luddico's group.
# usermod -G luddico -a git
# groups git
git : git luddico
This should give git access to any files that are owned by the luddico group, and have appropriate group permissions. Group permissions are the second "rwx" set listed in ls. The testfile I showed above only allows read access by the root group. If you wanted to give all members of that group write access, you would have to use chmod for that.
# ls -l testfile
-rw-r--r-- 1 root root 19 Jan 29 08:37 testfile
# chmod g+w testfile
# ls -l testfile
-rw-rw-r-- 1 root root 19 Jan 29 08:37 testfile
Now anyone in the root group can read or write to testfile. Apply the same concept to Luddico's files.
Best Answer
It looks like the NULL character is lost (or ignored), as if the listing includes "app" and "httpd", it will match the string "apphttpd".
So I've gone with calling "git ls-tree" multiple times for now to see if each individual file exists.