Конфликты между ACL и umask

У меня есть каталог, который может быть прочитан и записан парой групп Unix. Это достигается с помощью ACL. Давайте предположим, что я сделал это так:

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

Прекрасно работает, вся группа (и другие группы, которые я добавляю вот так) может читать / писать в этот каталог. НО есть одно исключение: когда кто-то создает подпапку с помощью mkdir -p затем этот каталог создается с разрешениями unix 0755, потому что значение umask по умолчанию - 022. Это приводит к проблеме, из-за которой другие пользователи группы больше не могут писать в эту подпапку, поскольку ACL теперь выглядит следующим образом:

group:group1:rwx            #effective:r-x

По какой-то причине этого не происходит при использовании "mkdir" (без аргумента -p). Одним из решений является установка значения umask на 002, но это действительно плохо, поскольку это также влияет на файлы и каталоги, созданные вне каталогов, контролируемых ACL, и эти файлы не должны быть доступны для записи группой по умолчанию.

Поэтому мне интересно, есть ли другая возможность решить эту проблему. Было бы идеально иметь возможность полностью отключить / проигнорировать старые разрешения в стиле Unix для каталога, управляемого ACL. Или отключите этот "эффективный ACL" материал. Это возможно? Или есть другой способ решить проблему с неперезаписываемыми каталогами, вызванную такими программами, как "mkdir -p"? В конце я хочу каталог, который полностью (и рекурсивно) читается и записывается в соответствии с настроенными мной ACL, и это никогда не должно изменяться (только путем изменения самих ACL).

Примечание: для воспроизведения проблемы:

$ 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