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 an explicit 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:

If you set an explicit ACL on a directory, the ACL is not automatically inherited by the directory's children. If you set an explicit 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–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
-r--r--r--   1 root     root      206663 May  4 11:52 file.1
     0:[email protected]:write_data/append_data/execute:deny
     1:[email protected]:read_data/write_xattr/write_attributes/write_acl/write_owner
         :allow
     2:[email protected]:write_data/append_data/execute:deny
     3:[email protected]:read_data:allow
     4:[email protected]:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:[email protected]:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Note that each user category ([email protected], [email protected], [email protected]) in this example has two ACL entries. One entry for deny permissions, and one entry is for allow permissions.

A description of this file ACL is as follows:

0:[email protected]

The owner is denied execute permissions to the file (execute:deny).

1:[email protected]

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 timestamps, 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:[email protected]

The group is denied modify and execute permissions to the file (write_data/append_data/execute:deny).

3:[email protected]

The group is granted read permissions to the file (read_data:allow).

4:[email protected]

Everyone who is not user or group 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:[email protected]

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 Feb 23 10:37 dir.1
     0:[email protected]::deny
     1:[email protected]:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:[email protected]:add_file/write_data/add_subdirectory/append_data:deny
     3:[email protected]:list_directory/read_data/execute:allow
     4:[email protected]:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:[email protected]:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

A description of this directory ACL is as follows:

0:[email protected]

The owner deny list is empty for the directory (::deny).

1:[email protected]

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 file's attributes such as timestamps, 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:[email protected]

The group cannot add to or modify the directory contents (add_file/write_data/add_subdirectory/append_data:deny).

3:[email protected]

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:[email protected]

Everyone who is not user or group 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:[email protected]

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.