Oracle Solaris ZFS Administration Guide

Setting ACLs on ZFS Files

As implemented with ZFS, ACLs are composed of ACL entries. ZFS provides a pure ACL model, where all files have an ACL. Typically, the ACL is trivial in that it only represents the traditional UNIX owner/group/other entries.

If you change the permissions of the file, a file's ACL is updated accordingly. In addition, if you remove a non-trivial ACL that granted a user access to a file or directory, that user could still have access to the file or directory because of the file or directory's permission bits that grant access to a group or to everyone. All access control decisions are governed by the permissions represented in a file or directory's ACL.

The primary rules of ACL access on a ZFS file follow:

ZFS processes ACL entries in the order they are listed in the ACL, from the top down.
Only ACL entries that have a “who” that matches the requester of the access are processed.
After an allow permission has been granted, it cannot be denied by a subsequent ACL deny entry in the same ACL permission set.
The owner of a file is granted the write_acl permission unconditionally, even if the permission is explicitly denied. Otherwise, any permission left unspecified is denied.

In cases of deny permissions or when an access permission for a file is missing, the privilege subsystem determines what access request is granted for the owner of the file or for superuser. This mechanism prevents owners of files from getting locked out of their files and enables superuser to modify files for recovery purposes.

If you set a non-trivial ACL on a directory, the ACL is not automatically inherited by the directory's children. If you set a non-trivial ACL and you want it to be inherited by the directory's children, you have to use the ACL inheritance flags. For more information, see Table 8–3 and Setting ACL Inheritance on ZFS Files in Verbose Format.

When you create a new file and depending on the umask value, a default trivial ACL, similar to the following, is applied:

$ ls -v file.1
-rw-r--r--   1 root     root      206663 May 20 14:09 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Note that each user category (owner@, group@, everyone@) has two ACL entries in this example. One entry is for deny permissions, and one entry is for allow permissions.

A description of this file ACL follows:

0:owner@: The owner is denied execute permission on the file (execute:deny).
1:owner@: The owner can read and modify the contents of the file (read_data/write_data/append_data). The owner can also modify the file's attributes such as time stamps, extended attributes, and ACLs (write_xattr/write_attributes /write_acl). In addition, the owner can modify the ownership of the file (write_owner:allow).
2:group@: The group is denied modify and execute permissions on the file (write_data/append_data/execute:deny).
3:group@: The group is granted read permissions to the file (read_data:allow).
4:everyone@: Everyone who is not the owner of the file or a member of the owning group of the file is denied permission to execute or modify the contents of the file and to modify any attributes of the file (write_data/append_data/write_xattr/execute/write_attributes/write_acl/write_owner:deny).
5:everyone@: Everyone who is not the owner of the file or a member of the owning group of the file is granted read permissions on the file and the file's attributes (read_data/read_xattr/read_attributes/read_acl/synchronize:allow). The synchronize access permission is not currently implemented.

When you create a new directory and depending on the umask value, a default directory ACL, similar to the following is applied:

$ ls -dv dir.1
drwxr-xr-x   2 root     root           2 May 20 14:11 dir.1
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

A description of this directory ACL follows:

0:owner@: The owner deny list is empty for the directory (::deny).
1:owner@: The owner can read and modify the directory contents (list_directory/read_data/add_file/write_data/add_subdirectory/append_data), search the contents (execute), and modify the directory's attributes such as time stamps, extended attributes, and ACLs (write_xattr/write_attributes/write_acl). In addition, the owner can modify the ownership of the directory (write_owner:allow).
2:group@: The group cannot add to or modify the directory contents (add_file/write_data/add_subdirectory/append_data:deny).
3:group@: The group can list and read the directory contents. In addition, the group has execute permission to search the directory contents (list_directory/read_data/execute:allow).
4:everyone@: Everyone who is not the owner of the file or a member of the owning group of the file is denied permission to add to or modify the contents of the directory (add_file/write_data/add_subdirectory/append_data). In addition, the permission to modify any attributes of the directory is denied (write_xattr/write_attributes/write_acl/write_owner:deny).
5:everyone@: Everyone who is not the owner of the file or a member of the owning group of the file is granted read and execute permissions on the directory contents and the directory's attributes (list_directory/read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow). The synchronize access permission is not currently implemented.