Bash – How to recursively apply default ACLs of a directory to its descendants

aclbashcommand linepermissions

If I have a directory with default ACL entries assigned to it, but some or all of its descendant files and sub-directories have access or default ACLs that do not agree with those defaults, how do I recursively (re)apply those default ACL entries to all descendants? There is a qualification. I wish to entirely replace all existing descendant ACLs except for the existing execute status of files. The intent otherwise is that all descendants should have the ACLs they would have if newly created in their current location.

Rogach asked "How do I set permissions recursively on a dir (with ACL enabled)?" but was looking to add a new ACL entry recursively rather than (re)applying an existing default ACL. Although not asked for by Rogach, Franklin Piat's answer to that question also offers a solution to my question, but I believe his solution is flawed. Piat suggests this pair of commands:

find . -mindepth 1 -type d| xargs -n 50 setfacl -b --set-file=<(getfacl . | sed -e 's/x$/X/')
find . -mindepth 1 -type f| xargs -n 50 setfacl -b --set-file=<(getfacl . | grep -v '^default:' | sed -e 's/x$/X/')

The flaws that I want to fix:

The current directory's access ACL is being propagated to descendants instead of its default ACL, which is not how I understand ACLs should work.
The execute bit is cleared for all files (sed is ineffective).
Typical sudoer policies prevent process substitution from working when root privileges are required. See "closefrom_override" option for sudoers(5).

Ideally I would also only need one command line to accomplish this one task.

Best Answer

I have come up with this ugly, inefficient solution but surely there's a better way:

( cd '/some/dir' && sudo find . -mindepth 1 -path './leave/alone' -prune -o \( -type d -exec bash -c 'getfacl -cd . | sed -nre "p;/^\$/!s/^/default:/p" | setfacl -bM - "{}"' \; \) -o \( -type f -exec bash -c 'getfacl -cd . | sed -re "/^#/!s/x\$/X/" | setfacl -bM - "{}"' \; \) )

Some comments about that monstrosity:

I've included a sub-directory exclusion to demonstrate that frequent requirement.
The cd eliminates the error-prone repetition of the source directory path and the outer parentheses make that change temporary.
The use of bash is needed because "-exec" doesn't allow pipelines. It also avoids that '!' character invoking history substitution and resulting in the infamous “event not found” error.
For sub-directories we must apply the source default ACLs as both access ACLs and default ACLs.
For files we must apply source default ACLs as access ACLs but apply no default ACLs at all if we wish to avoid the “Only directories can have default ACLs” warnings from setfacl.
For files we need to replace 'x' permissions from the source default ACLs with 'X' in order that we don't end up forcing all files to become executable. This solution also preserves the executable status of existing files, but only because we use “-bM -” rather than “--set-file=-” with setfacl.
This command line is very inefficient because I don't know of a way to use “-exec ... +” or xargs instead of “-exec ... \;”.
This command line works, but beware that descendant files get ACLs that are effectively equivalent but not technically equivalent to what occurs when newly creating a new descendant file.

The "Unix philosophy" is fantastic, but the task I'm trying to accomplish is needed too often for it to require such an unwieldy command line. Is there a better way aside from lobbying for additional features in setfacl?

Background

When a file is created on a Linux system the default permissions 0666 are applied whereas when a directory is created the default permissions 0777 are applied.

example 1 - file

Suppose we set our umask to 077 and touch a file. We can use strace to see what's actually happening when we do this:

$ umask 077; strace -eopen touch testfile 2>&1 | tail -1; ls -l testfile
open("testfile", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3
-rw-------. 1 root root 0 Sep 4 15:25 testfile

In this example we can see that the system call open() is made with the permissions 0666, however when the umask 077 is then applied by the kernel the following permissions are removed (---rwxrwx) and we're left with rw------- aka 0600.

example - 2 directory

The same concept can be applied to directories, except that instead of the default permissions being 0666, they're 0777.

$ umask 022; strace -emkdir mkdir testdir; ls -ld testdir
mkdir("testdir", 0777)                  = 0
drwxr-xr-x 2 saml saml 4096 Jul  9 10:55 testdir

This time we're using the mkdir command. The mkdir command then called the system call mkdir(). In the above example we can see that the mkdir command called the mkdir() system call with the defaul permissions 0777 (rwxrwxrwx). This time with a umask of 022 the following permissions are removed (----w--w-), so we're left with 0755 (rwxr-xr-x) when the directories created.

example 3 (Applying default ACL)

Now let's create a directory and demonstrate what happens when the default ACL is applied to it along with a file inside it.

$ mkdir acldir
$ sudo strace -s 128 -fvTttto luv setfacl -m d:u:nginx:rwx,u:nginx:rwx acldir

$ getfacl --all-effective acldir
# file: acldir
# owner: saml
# group: saml
user::rwx
user:nginx:rwx          #effective:rwx
group::r-x          #effective:r-x
mask::rwx
other::r-x
default:user::rwx
default:user:nginx:rwx      #effective:rwx
default:group::r-x      #effective:r-x
default:mask::rwx
default:other::r-x

Now let's create the file, aclfile:

$ strace -s 128 -fvTttto luvly touch acldir/aclfile

# view the results of this command in the log file "luvly"
$ less luvly

Now get permissions of newly created file:

$ getfacl --all-effective acldir/aclfile 
# file: acldir/aclfile
# owner: saml
# group: saml
user::rw-
user:nginx:rwx          #effective:rw-
group::r-x          #effective:r--
mask::rw-
other::r--

Notice the mask, mask::rw-. Why isn't it mask::rwx just like when the directory was created?

Check the luvly log file to see what default permissions were used for the file's creation:

$ less luvly |grep open |tail -1
10006 1373382808.176797 open("acldir/aclfile", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3 <0.000060>

This is where it get's a little confusing. With the mask set to rwx when the directory was created, you'd expect the same behavior for the creation of the file, but it doesn't work that way. It's because the kernel is calling the open() function with the default permissions of 0666.

To summarize

Files won't get execute permission (masking or effective). Doesn't matter which method we use: ACL, umask, or mask & ACL.
Directories can get execute permissions, but it depends on how the masking field is set.
The only way to set execute permissions for a file which is under ACL permissions is to manually set them using chmod.

References

acl man page

How to allow rwx access to a specific group with ACLs

I think you were missing the "recursive" parameter:

setfacl -Rm g:developer:rwx /opt/spago41/