Richacl Examples

Table Of Contents

“Minimal” Richacls, Output Formats

Every file on a file system always has some file permissions set. In the standard POSIX file permission model, the file permission bits in the file mode determine access to the file. When a file has a “real” POSIX ACL or richacl, the ACL determines access to the file. Even the standard POSIX file permission bits can be represented as equivalent ACLs, however. Richacls can be displayed and manipulated with the getrichacl command-line utility. POSIX ACLs can be displayed and manipulated with the getfacl and setfacl utilities.

The first example demonstrates how getrichacl shows a file with file permission bits 0644 (that is, without a “real” richacl). The richacl command-line utility supports a short output format where each permission is represented by a single letter and disabled permissions are represented a dashes, and a more verbose --long output format.

The richacl permission model distiguishes between the right to write to a file (write_data) and the right to append to a file (append_data), which does not allow overwriting existing data. The POSIX Write permission maps to both write_data and append_data.

The special group everyone@ includes all users, including the owner and the owning group: this differs from the POSIX other class, which is distinct from the owner and group class. The acl does not need a separate entry for the owning group because the owning group has the same permissions as everyone@ else.

Directories are shown like files, except that the richacl permission model has separate permissions for creating a file (add_file), creating a directory (add_subdirectory), and for deleting a directory entry (delete_child). The POSIX Search permission (x) maps to execute, and the POSIX Write permission maps to add_file, add_subdirectory, and delete_child.

In addition, directories use different --long text forms for some permissions.

“Real” Richacls

Richacls can be used for granting permissions which the file permission bits alone cannot represent anymore. For example, we can grant user Tim the right to read, write, and append to a file, change the acl and file permission bits (write_acl), and take ownership of the file (write_owner).

Changing the acl of a file also sets the file permission bits. In this case, they change from 0644 to 0664 to indicate that members of the group class are granted read_data, write_data, and append_data access. The file permission bits are set to a superset of the permissions that the acl grants as closely as possible: the POSIX Write permission indicates that a particular member of the group class can have write_data or append_data access, both, or none of these permissions. The fact that Tim is also granted write_acl and write_owner access does not show in the file permission bits, but it does show in the richacl output.

Please note that only versions of the ls utility with richacl support will show a plus sign for files which have a richacl.

Changing The File Permission Bits

When the permission bits of a file are changed, POSIX requires that the new file permission bits define the maximum permissions that a process can be granted, including through acls. For example, changing the file permissions to the value that they already have from the previous example disables the write_acl and write_owner permissions for Tim:

Note that the algorithm for applying the new file permission bits to the acl also moves the everyone@ entry to the end of the acl; this does not change the permissions that the acl grants. Further restricting the permissions so that only the owner retains POSIX Read and Write access leads to the following result:

Changing The File Permission Bits: Masks

The previous example shows that chmod can be quite destructive to an acl. This strictness is necessary to ensure the security of applications which are not aware of richacls. Nevertheless, losing all the permissions stored in an acl is undesirable: it can be dificult to reconstruct that information.

Richacls lessen this problem by masking or disabling unwanted permissions instead of removing them from the acl. A restrictive chmod followed by a less restrictive one will make such masked permissions reappear. For example, if we change the file permission bits of f back from 0600 to 0664, Tim regains rwp access, and everyone else regains r access:

Under The Hood

Internally, three file masks are used for disabling permissions, and chmod only changes these file masks instead of changing the actual acl. The permission check algorithm looks at the acl as well as at the file masks.

The getrichacl utility normally only shows the effective permissions and hides permissions which are not included in the file masks. The file masks and underlying unmasked acl can be shown with getrichacl's --raw option:

These examples show that chmod sets a special masked acl flag (m) which indicates that the three file masks are “active”.

Inheritance At File Create Time

So far, we have looked only at the effective permissions of a file. In addition to that, the richacl of a directory can contain entries which files and directories created inside that directory will inherit. The way this is implemented is through flags: each acl entry can have the file_inherit (f), directory_inherit (d), or both flags set. Non-directories will inherit all the file_inherit entries; directories will inherit all the directory_inherit entries.

The following example shows how inheritable acl entries are created. Pay attention to the flags field before the entry type (allow), which makes all three acl entries inheritable by files and directories:

When files or directories are created on a POSIX compliant system, a create mode is specified which defines the maximum possible permissions. Applying the create mode to an acl essentially has the same effect as doing a chmod. It affects only the effective permissions; the inheritable permissions remain unchanged.

The mkdir command uses 0777 as the create mode. Applying this create mode to the inherited acl entries results in a new acl entry with the original permissions of the inherited ace and with the inherit_only (i) flag set. This flag makes the entry ineffective for permission checking, but leaves it effective for inheritance. The permissions effective for permission checking are put in a separate acl entry with all inheritance flags cleared.

Similarly, the touch command uses 0666 as the create mode. Nothing can inherit the permissions of a file, so the f and d flags are cleared and no inherit-only acl entries are necessary.

Changing The File Permission Bits: File Creation

When files are created, the same masking approach as described above in Changing The File Permission Bits: Masks is used: the create mode only affects the file masks, and the inherited acl itself remains unchanged. Some of the permissions disabled by the create mode can be “reactivated” with chmod:

Effective Permissions

It can be difficult to see which permissions a richacl grants to a particular user or group. The --access command of the getrichacl utility helps in this case; it reports the actual permissions that a user or group has for a particular file.

The following example shows the permissions of the current user:

The permissions of a particular other use can be shown with:

The permissions of a particular group can be shown with:

Features Not Mentioned Here

Automatic Inheritance

Automatic Inheritance is a permission inheritance scheme which allows changes to the inheritable permissions of a parent directory to “automatically” propagate to all its children in a controlled way. Automatically here means that the utility changing the permissions (setrichacl, the Windows ACL Editor, etc.) walks the directory tree and updates all ACLs.

Automatic Inheritance is supported, but it does not interact well with explicitly setting the file permissions, which happens when doing a chmod or when applying the create mode while creating files.

Deny Entries

In addition to allow entries, richacls also support deny entries. Deny entries are rarely needed, and their use is discouraged. When doing a chmod with fewer permissions for the owner class than for the group class or fewer permissions for the group class than for the other class, deny entries may have to be inserted into an acl automatically though.

Copyright (C) Andreas Grünbacher <>, January 2016