I have run into this funky problem with ACL and git at work, and I cannot for the life of me figure it out. I’m not sure if it’s a bug, wrong expectation on my part, or just plain ole user error.
I have a directory that is setting the default ACL permissions. Those are being inherited just fine by children (files and directories), including the effective mask. However, when I clone a new repository using git, the default effective mask is ignored. And I can’t figure out why.
Specifically, here’s what I’m looking at.
Setting the permissions:
# mkdir testing
# setfacl -m g:users:rwx testing
# setfacl -m d:g:users:rwx testing
# setfacl -m m:rwx testing
# setfacl -m d:m:rwx testing
The ACL permissions:
$ getfacl testing
# file: testing
# owner: root
# group: root
user::rwx
group::r-x
group:users:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:users:rwx
default:mask::rwx
default:other::r-x
You can see that the default effective masks are properly set.
When I create a sub-directory, it’s ACL settings are inherited properly as well:
$ mkdir dir
$ getfacl dir
# file: dir
# owner: steve
# group: users
user::rwx
group::r-x
group:users:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:users:rwx
default:mask::rwx
default:other::r-x
That works great and dandy and fine.
The problem I run into is when I use git to clone a repo:
$ git clone [email protected]:shell/shell.git
$ getfacl shell
# file: shell
# owner: steve
# group: users
user::rwx
group::r-x
group:users:rwx #effective:r-x
mask::r-x
other::r-x
default:user::rwx
default:group::r-x
default:group:users:rwx
default:mask::rwx
default:other::r-x
The effective mask and the default effective mask have dropped from the default (rwx) to something else (r-x), and I have *no* idea why.
Hopefully someone out there may have a clue. I’m stumped.
I would call this a bug in git clone.
In git/builtin/clone.c, mkdir(work_tree, 0755) is called if work_tree directory does not exist. The 0755 mode ends up changing the effective mask acl entry on the directory.
You can test this by doing mkdir -m 0755 foo in your testing directory.
I think git clone should be calling mkdir(work_tree, 0777) and let the umask take care of the default permissions.
As far as I know, git doesn’t store permissions save the executable bit.
Is git running a chmod on the clone dir? ISTR that messes up the mask if the permissions are changed in certain ways.
From man acl:
“If the ACL has an ACL_MASK entry, then the permissions defined for the file group correspond to the permissions of the ACL_MASK entry.”
Hope this helps.
My bet would be umask.
Note that ACL-unaware processes that touch file permissions touch ACL owner permissions (same as for old file permissions), ACL mask (instead of old group permissions) and others (same as for old file permissions).
So if git does chmod(rwxr-xr-x) you get result of setfacl -m u::rwx,m::rx,o::rx
I have been struggling with that too some time ago. Here is what I remember.
If you want proper inheritance you also need to set the defaults with “-d”, e.g. “setfacl -d -m g:users:rwx testing”
Also if I remember correctly the primary unix group the file or directory belongs to needs “rw” rights so the ACL group also have at least that right.
Cheers,
Thomas
Git uses mkdir(work_tree, 0755) to create the work tree (I wonder why – all other places in git use 0777, trusting umask to be sane), and group permissions are masking the ACL mask:
root@ghostwheel ~/foo/testing # mkdir a; getfacl a | grep ^mask
mask::rwx
root@ghostwheel ~/foo/testing # mkdir -m0755 b; getfacl b | grep ^mask
mask::r-x
Git doesn’t do permissions, so expectations not met.
Git uses mkdir(work_tree, 0755) to create the work tree (I wonder why – all other places in git use 0777, trusting umask to be sane), and group permissions are masking the ACL mask:
I had the same issue (though with unison not git) and it drove me mad. After hours of trail and error eventually this was the solution: http://muzso.hu/2008/01/22/default-permissions-with-libpam-umask