'setfacl' permissions don't apply to directories created by git clone?

Question

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?

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

Answer 2

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

• What is Umask and How To Setup Default umask Under Linux?
• git clone produces different permissions on different servers

Answer 3

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.