Setting ACLs on ZFS Files

As implemented with ZFS, ACLs are composed of an array 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.

ZFS files still have permission bits and a mode, but these values are more of a cache of what the ACL represents. As such, if you change the permissions of the file, the 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 group or 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 are as follows:

• 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.

• Once 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 the file is granted the write_acl permission unconditionally, even if the permission is explicitly denied. Otherwise, any permission left unspecified is denied.

  In the cases of deny permissions or when an access permission 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 an non-trivial ACL and you want it inherited to the directory's children, you have to use the ACL inheritance flags. For more information, see Table 7-4 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 Jun 23 15:06 file.1
     0:owner@:read_data/write_data/append_data/read_xattr/write_xattr
         /read_attributes/write_attributes/read_acl/write_acl/write_owner
         /synchronize:allow
     1:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
     2:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Each user category (owner@, group@, everyone@) has an ACL entry in this example.

A description of this file ACL is as follows:

0:owner@

The owner can read and modify the contents of the file (read_data/write_data/append_data/read_xattr). The owner can also modify the file's attributes such as timestamps, extended attributes, and ACLs (write_xattr/read_attributes/write_attributes/read_acl/write_acl). In addition, the owner can modify the ownership of the file (write_owner:allow).

The synchronize access permission is not currently implemented.

1:group@

The group is granted read permissions to the file and the file's attributes (read_data/read_xattr/read_attributes/read_acl:allow).

2:everyone@

Everyone who is not user or group is granted read permissions to 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 a new directory is created and depending on the umask value, a default directory ACL is similar to the following:

$ ls -dv dir.1
drwxr-xr-x   2 root     root           2 Jul 20 13:44 dir.1
     0:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/delete_child
         /read_attributes/write_attributes/read_acl/write_acl/write_owner
         /synchronize:allow
     1:group@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow
     2:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

A description of this directory ACL is as follows:

0:owner@

The owner can read and modify the directory contents (list_directory/read_data/add_file/write_data/add_subdirectory/append_data) and read and modify the file's attributes such as timestamps, extended attributes, and ACLs (/read_xattr/write_xattr/read_attributes/write_attributes/read_acl/write_acl). In addition, the owner can search the contents (execute), delete a file or directory (delete_child), and can modify the ownership of the directory (write_owner:allow).

The synchronize access permission is not currently implemented.

1:group@

The group can list and read the directory contents and the directory's attributes. In addition, the group has execute permission to search the directory contents (list_directory/read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow).

2:everyone@

Everyone who is not user or group is granted read and execute permissions to 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.