ACL Interaction With Permission Bits

In ZFS files, the UNIX permission bits correspond to the ACL entries, but are cached. When you change a file's permission bits, the file's ACL is updated accordingly. Likewise, modifying a file's ACL causes changes in the permission bits.

For more information about permission bits, see chmod(1).

The following examples show the relationship between a file or directory's ACLs and the permission bits and how permission changes in one affect the other.

Example 2-2 ACLs and Permission Bits

The first example begins with the following ACL for file.2, whose permission bits are set to 644.

$ ls -v file.2
-rw-r--r--   1 root     root        2693 Jul 20 14:26 file.2
Permission bits are 644.
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

The chmod command removes the ACL entry for everyone@. Accordingly, the read permission bits for everyone are also removed and are changed to 640.

$ chmod A2- file.2
Access is removed for everyone@
$ ls -v file.2
-rw-r-----   1 root     root        2693 Jul 20 14:26 file.2Permission bits become 640.
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

Next, the ACL is replaced with just read_data/write_data permissions for everyone@. No owner@ or group@ ACL entry exists to override the permissions for owner and group. Consequently, the permission bits become 666.

$ chmod A=everyone@:rw:allow file.2
$ ls -v file.2
-rw-rw-rw-   1 root     root        2440 Jul 20 14:28 file.3Permission bits become 666.
0:everyone@:read_data/write_data:allow

Next, the ACL is replaced with read permissions just for user Alice. The command, however, leaves no trivial ACL entries. Consequently, the permission bits are set to 000, which denies Alice access to file.2. The file effectively becomes inaccessible.

$ chmod A=user:alice:r:allow file.2
$ ls -v file.2
----------+  1 root     root        2440 Jul 20 14:28 file.3Permission bits become 000.
0:user:alice:read_data:allow

The example ends with showing how setting permission bits also update the ACL. The bits for file.2 are set to 655. Automatically, default trivial ACL permissions are set.

$ chmod 655 file.2
$ ls -v file.3
-rw-r-xr-x   1 root     root        2440 Jul 20 14:28 file.3Permission bits set to 655.
0:user:alice:read_data:allow
1:owner@:execute:denyBased on 655 bits, ACL execute permission is denied.
2:owner@:read_data/write_data/append_data/read_xattr/write_xattrDefault ACL entries restored.
/read_attributes/write_attributes/read_acl/write_acl/write_owner
/synchronize:allow
3:group@:read_data/read_xattr/execute/read_attributes/read_acl
/synchronize:allow
4:everyone@:read_data/read_xattr/execute/read_attributes/read_acl
/synchronize:allow

Example 2-3 ACL Properties and Modified ACL Permissions

The following examples illustrate how specific aclmode and aclinherit property values affect ACL behavior. If these properties are set, ACL permissions for a file or directory are either reduced or expanded to be consistent with the owning group.

In this example, the administrator who runs the zfs set commands must be assigned the ZFS File System Management rights profile. To run the chown command, the administrator is assigned the Object Access Management rights profile.

Suppose that the aclmode property is set to mask and the aclinherit property is set to restricted in the pool, and that the original file and group ownership and ACL permissions are as follows:

$ pfbash ; zfs set aclmode=mask system1/data
$ zfs set aclinherit=restricted system1/data
$ ls -lV file.1
-rwxrwx---+  1 root     root      206695 Aug 30 16:03 file.1
user:amy:r-----a-R-c---:-------:allow
user:rory:r-----a-R-c---:-------:allow
group:sysadmin:rw-p--aARWc---:-------:allow
group:staff:rw-p--aARWc---:-------:allow
owner@:rwxp--aARWcCos:-------:allow
group@:rwxp--aARWc--s:-------:allow
everyone@:------a-R-c--s:-------:allow

To understand the meaning of the values set for the two properties, see ACL Properties.

A chown operation changes file.1's ownership to Amy and the group Staff.

$ chown amy:staff file.1

Amy then changes file.1's permission bits to 640. Because of the ACL properties that were previously set, the permissions for the groups in the ACL are reduced in order to not exceed the permissions of the owning Staff.

$ su - amy
$ chmod 640 file.1
$ ls -lV file.1
-rw-r-----+  1 amy      staff     206695 Aug 30 16:03 file.1
user:amy:r-----a-R-c---:-------:allow
user:rory:r-----a-R-c---:-------:allow
group:sysadmin:r-----a-R-c---:-------:allow
group:staff:r-----a-R-c---:-------:allow
owner@:rw-p--aARWcCos:-------:allow
group@:r-----a-R-c--s:-------:allow
everyone@:------a-R-c--s:-------:allow

Amy then changes the permission bits to 770. Consequently, the permissions of the groups in the ACL are also changed to match the permission of the owning group Staff.

$ chmod 770 file.1
$ ls -lV file.1
-rwxrwx---+  1 amy      staff     206695 Aug 30 16:03 file.1
user:amy:r-----a-R-c---:-------:allow
user:rory:r-----a-R-c---:-------:allow
group:sysadmin:rw-p--aARWc---:-------:allow
group:staff:rw-p--aARWc---:-------:allow
owner@:rwxp--aARWcCos:-------:allow
group@:rwxp--aARWc--s:-------:allow
everyone@:------a-R-c--s:-------:allow