Setting Default File Permissions

This page will review how to set default file permissions for a directory using Access Control Lists (ACL). 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.

This is normal behavior and can be overridden with manually running setfacl (or chmod if only the three basic permissions need to be changed).

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, and there is an #effective:r-- message next to the group:: and group:a1983: entries. The latter message is showing that the permissions for group:: and group:a1983: are being overridden by the mask::r-- entry.

This is because touch uses a "mode" parameter of 666 when creating the new file object (6 translates to rw-, see Permissions as Octal Numbers). Since the ACL_MASK entry is used to limit the group: entries such that the effective permissions do not exceed the "mode" parameter. Since the "mode" parameter does not feature execute permissions for ACL_GROUP_OBJ, the mask: entry is set to remove the effective execute permission from the group: entries. Similarly, the user: is changes directly to comply with the "mode" parameter settings.

This is normal behavior and it actually a "feature". To make the file executable by the group: entries, simply use setfacl to change the mask entry:

$ setfacl -m m:rx testfile

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

Note that the user: entry did not change and, thus, the file is still not executable by the user. This maybe changed by using the standard chmod command or by using setfacl:

$ chmod +x testfile #equivalent to setfacl -m u:rwx testfile

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

Directories Require Executable Permissions

In order to give "full" access to a directory, the user must have read and execute permissions to that directory. With only read permissions, a user can view the contents of the directory, but may not actually enter it.

System Specific Instructions

NAS

Currently, the group ID of PHASTA members is a1983. To grant the group r-x permissions to your /nobackup/ directory:

• Run setfacl -Rd -m g:a1983:rx /nobackup/$USER
  • This will make all new files inherit those permissions
• Run setfacl -R -m g:a1983:rx /nobackup/$USER
  • This will give all current files group permissions

Note: The issue with files not inheriting executable permissions is present here. This must be fixed on a file-by-file basis unfortunately using either setfacl -m m:rx testfile or (if the file group is the group you want to give permissions to) chmod g+x testfile.