Conflicts between ACLs and umask

Question

I have a directory which can be read and written by a couple of unix groups. This is achieved by using ACLs. Let's assume I did it like this:

mkdir /tmp/test
setfacl -d -m g:group1:rwx /tmp/test

Works great, the whole group (And other groups I add like this) can read/write to this directory. BUT there is one exception: When someone creates a subfolder by using mkdir -p then this directory is created with the unix permissions 0755 because the default umask is 022. This results in the problem that other users of the group can no longer write to this subfolder because the ACL now looks like this:

group:group1:rwx            #effective:r-x

For some reason this doesn't happen when using "mkdir" (Without -p argument). One solution is setting the umask to 002 but this is really a bad thing because this also affects files and directories created outside of the ACL-controlled directories and these files should not be group writable per default.

So I wonder if there is another possibility to solve this problem. It would be perfect to be able to completely disable/ignore the old unix-style permission stuff for a ACL-controlled directory. Or disable this "effective ACL" stuff. Is that possible? Or is there another way to solve the problem with unwritable directories caused by programs like "mkdir -p"? In the end I want a directory which is completely (and recursively) readable and writable according to the ACLs I have configured and this should never change (Only by modifying the ACLs itself).

---

Note: to reproduce the problem:

$ mkdir /tmp/test
$ setfacl -d -m g:group1:rwx /tmp/test
$ umask 0022
$ mkdir /tmp/test/aa
$ mkdir -p /tmp/test/bb
$ ls -log /tmp/test
drwxrwxr-x+ 2 4096 Mar  9 23:38  aa
drwxr-xr-x+ 2 4096 Mar  9 23:38  bb

$ getfacl /tmp/test/bb | grep ^group:group1
group:group1:rwx                     #effective:r-x

Answer 1

It is a bug with gnu mkdir: http://savannah.gnu.org/bugs/?19546 There is no way to disable the traditional Unix permissions. Since mkdir works you could write a shell function that overrides mkdir. In the shell function look for a -p in the args and run a series of non-p-using mkdirs instead.

Many Linux-based systems are now using umask 0002 with user-private groups so this problem doesn't come up.

Answer 2

It was a bug with gnu mkdir (#14371), it was fixed in coreutils 8.22.

• affected: Debian Wheezy 7, RHEL/CentOS 5 and 6 are affected (and probably Ubuntu Trusty 14.04)
• not affected: Debian 8 Jessie, RHEL/CentOS 7 (and probably Tbuntu Utopic 14.10)

There are a few workaround.

Workaround #1: wrapper (already suggested by Mark Wagner)

Since mkdir works you could write a shell function that overrides mkdir (or a script /usr/local/bin/mkdir as this is usualy before /bin). That script look for a -p in the args then recursively invoke mkdir without "-p".

Workaround #2: umask 0002

If you can control the script that calls mkdir, you can set the mask before invoking mkdir:

(umask 0002 ; mkdir -p /path/to/dir)

---

Your other questions:

So I wonder if there is another possibility to solve this problem. It would be perfect to be able to completely disable/ignore the old unix-style permission stuff for a ACL-controlled directory.

No, Permission are required for compatibility, also read Why does chmod(1) on the group affect the ACL mask?

Or disable this "effective ACL" stuff.

No

Answer 3

Have you tried setting the setgid bit on the containing directory? This should enforce the same permissions on all new files and directories in it.