Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
    
If you use the SGID bit then the ACL should be: d:g::rwx –  Hauke Laging Jun 21 '13 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 '13 at 14:18

3 Answers 3

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).

share|improve this answer
    
The strace command isn't working. Am I supposed to replace file in the command with something? If yes, what? –  its_me Jun 21 '13 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 '13 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 '13 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 '13 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 '13 at 15:48

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

share|improve this answer
    
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 '13 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 '13 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 '13 at 7:23

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.