Setting per-directory umask using ACLs

Question

We want to mimic the behavior of a system-wide 002 umask on a certain directory foo, in order to ensure the following result:

1. All sub-directories created underneath foo will have 775 permissions
2. All files created underneath foo and subdirectories will have 664 permissions
3. 1 and 2 will happen for files/dirs created by all users, including root, and all daemons.

Assuming that ACL is enabled on our partition, this is the command we came up with:

setfacl -R -d -m mask:002 foo

... but this doesn't work. New files created in the directory end up looking like:

-rw--w-r--+

When I run getfacl on the new file, I get:

# file: newfile.py
# owner: root
# group: agroup
user::rw-
group::rwx #effective:-w-
mask::-w-
other::r--

In other words, applying a mask:200 with ACL is not the same as applying umask 200.

So is there a way to apply a per-directory umask with an ACL?

Answer 1

This is a typical job for ACLs :-)

Your example

$ mkdir /tmp/foo

Set the permissions for the directory itself

$ setfacl -m g::rwx -m o::rx  /tmp/foo

Set the permissions for the newly created directory and files in that directory.

$ setfacl -m default:g::rwx -m o::rx  /tmp/foo

Test

$ mkdir /tmp/foo/bar
$ touch /tmp/foo/bar/baz.py
$ ls -ld /tmp/foo/bar /tmp/foo/bar/baz.py
drwxrwxr-x+ 2 jdoe jdoe 4096 Mar 10 00:06 /tmp/foo/bar
-rw-rw-r--  1 jdoe jdoe    0 Mar 10 00:06 /tmp/foo/bar/baz.py

Explanations

• The concept of mask is very different with ACL and Unix permissions mask. the ACL's mask is an attribute of the file... which restrict the maximum permission granted through ACL (mask:r-x + group:foo:rwx => effective permissions = r-x)
• Warning: modifying the Unix permission of the group, also modifies the ACL's mask (by design!).

Suggestions

• Use setgid (like chmod 2755), so you control which group can write to the file.
• and/or explicitly grant permissions to a group setfacl -m group:dev_team:rwx

Answer 2

You can use a dnotify and script triggered each time a file is created. See: https://serverfault.com/a/127686/30946