linux - Conflicts between ACLs and umask

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

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.