Setting Default File Permissions

This page will review how to set default file permissions for a directory. This is often used when working in HPC "scratch" directories where members of the same research group (like us) want to give each other some default file permissions on every file created in those directories, regardless of who created them.

The basis of this is to edit the ACL entries of the directories that we want default file permissions to apply to. To see more information on how ACL and file permissions work, see File Permissions Basics and ACL.

Setting ACL Rules

For most POSIX file systems, this can be done via setfacl (see manpage here). For fancier filesystems, you may need to use other commands/tools to perform the same effective operation.

To set a ACL entry, use the -m to modify the given entry. The format for the ACL entry is identical to what is displayed when running getfacl on a file. Generalized, it takes the form:

[d[efault]:] [(u[ser]|g[roup]|m[ask]|o[ther]):](uid|gid|) [:perms]

Examples

Using the user ID sfseiei and group ID meisters

Give a user read access to a file object:

setfacl -m u:sfseiei:r fileobj

Give a group read and write access to a file object:

setfacl -m g:meisters:rw fileobj

Give a group read and write access to a directory and it's contents recursively

setfacl -R -m g:meisters:rw directory

• The -R flag is used for recursively applying the ACL entry

Note that any new files created in this directory or subdirectories will not be readable or writable by members of the group

Give a group read and write access to a directory, it's contents, and have new files inherit these rules

setfacl -Rd -m g:meisters:rw directory

• The -d flag denotes that the changes should be added as a ACL default entry.
  • This makes any new files inherit these ACL default entries, but does not necessarily mean that they will be effective. See Common "Gotchas"
• See Custom Permissions for more information on the importance and function of ACL default entries.

Common "Gotchas"

Newly Created File Only Doesn't Fully Inherit Default ACL Rules

tl;dr ACL Default entries are not the only thing that controls the permissions of new files. See Custom Permissions for deeper explanation.

This is probably most common with files that don't inherit the executable permission from the default ACL. In How are new file permissions set?, it is explained that the ACL_MASK (among others) will be set such that the resulting ACL permissions do not exceed the permissions set by the "mode" parameter (which is used by the program creating the file). Often, this "mode" parameter does not include execute permissions (with the primary exception being compilers, which will set binaries with execute permissions).

This is normal behavior and can always be overridden with `chmod`.

Example:

I have a directory with the following ACL entries:

$ getfacl .
# file: .
# owner: jrwrigh7
# group: a1983
user::rwx
group::r-x
group:a1983:r-x
mask::r-x
other::---
default:user::rwx
default:group::r-x
default:group:a1983:r-x
default:mask::r-x
default:other::---

Note that all the default: entries have execute permissions except other

I'll create new file in that directory using `touch`:

$ touch testfile

$ getfacl testfile 
# file: testfile
# owner: jrwrigh7
# group: a1983
user::rw-
group::r-x                      #effective:r--
group:a1983:r-x                 #effective:r--
mask::r--
other::---

We see that the file did inherit the default: ACL entries for group::, group:a1983:, and other::. However, the mask:: and user:: are different than its corresponding default: value.

This is because touch uses a "mode" parameter of 666 when creating the new file object (6 translates to -wx, see Custom Permissions