3

Here's how I am setting permissions for my website's root directory i.e. ~/public_html, where the files that my website serves are placed:

sudo chgrp -R www-data ~/public_html
chmod g+s ~/public_html
chmod g+rwx ~/public_html
setfacl -m d:g:www-data:rwx ~/public_html
  • Command #1 gives "www-data" group ownership access to ~/public_html;
  • #2 sets the group ID, so that all new directories/files within are also owned by "www-data" group
  • #3 sets access permissions for the group "www-data" on the directory to 775;
  • #4 makes sure that the same apply to all new directories/files created within ~/public_html.

It's working great, as it should. All new created directories and files inherit the forced permissions.

The problem is with directories created by git clone (after I do cd ~/public_html && git clone ....).

UPDATED: The directory DOES inherit the group ID (i.e. "www-data" owns the newly created directory), BUT NOT the access permissions (775 for directories and 664 for files). Also, it's just the top-level directory that git creates. Every directory and file withing inherit permissions just as they should. Could it be that the Debian git package doesn't have the fix for this bug yet?

What am I doing wrong? Rather, how exactly should I be doing it?

Improve this question
2
  • If you use the SGID bit then the ACL should be: d:g::rwx
    – Hauke Laging
    Jun 21, 2013 at 14:14
  • @HaukeLaging Yes, I now see it that it's kinda redundant, if that's what you meant. But that didn't change anything.
    – its_me
    Jun 21, 2013 at 14:18

3 Answers 3

Reset to default
1

Probably git overwrites the GID and the ACLs after the files have been created (like a simple mv does when moving cross device). You can check that by running it through strace (strace -f -o git.strace -e trace=file).

Improve this answer
7
  • The strace command isn't working. Am I supposed to replace file in the command with something? If yes, what?
    – its_me
    Jun 21, 2013 at 14:25
  • @its_me The command should create a file with the name git.strace. trace=file is correct; that limits the trace output to file related syscalls.
    – Hauke Laging
    Jun 21, 2013 at 14:27
  • Something's wrong with the command. I get usage instructions showing valid options and stuff, when I run the command.
    – its_me
    Jun 21, 2013 at 14:32
  • 2
    @its_me are you putting the command you're running at the end of the strace command? I think Hauke meant for that to be implied.
    – Bratchley
    Jun 21, 2013 at 14:48
  • @HaukeLaging Sorry for the delay; unexpected problem on my PC. Here's the output of strace: pastebin.com/RVbiaaXy . It has this line mkdir("dropplets", 0755) = 0 -- so, does it mean, Git is forcing the directory permissions, and thereby not adhering to ACLs? Or am I wrong?
    – its_me
    Jun 21, 2013 at 15:48
1

If you're seeing different permissions using git clone then it's likely your umask which is causing this:

$ umask
0002

The new files being created when you run the git clone command are being created with permissions based on what your umask specifies. Umask says which bits should be masked off. So in the above example any new files I create with a umask of 0002 would have the other write bit turned off.

References

Improve this answer
3
  • I don't think so (although I am not sure). I think Git is actually setting the directory permissions to 0755. Please read this comment for more info: unix.stackexchange.com/questions/80267/… and let me know what you think
    – its_me
    Jun 21, 2013 at 15:50
  • I think your issue might ultimately be this problem: stackoverflow.com/questions/10637416/…. See the comments on the accepted answer.
    – slm ♦
    Jun 21, 2013 at 17:40
  • Yes, that's where I found the bug (linked in my question). The thing is, the fix was released in January, and doubt it isn't yet been included in the Debian package.
    – its_me
    Jun 22, 2013 at 7:23
0

It's possible that git is failing to clone the extended attributes of the public_html directory.

ACLs (as well as SELinux file labels) under Linux are implemented using filesystem-based extended attributes (see man pages for attr, getfattr, setfattr). Extended attributes must be explicitly copied in order for them to be preserved. Most file utilities (mv, cp, tar, rsync, rm, et al.) in most modern Linux distros were updated to support extended attributes (and, by extension, ACLs).

Redo your strace but leave out the -e trace=file part, pipe it to grep xattr, and then see if there are any calls to setxattr.

strace -f 2>&1 git clone | grep xattr

If you see no output, then git, or at least the one you're using, doesn't support extended attributes.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .