The Oracle Solaris ACL model fully supports the interoperability that NFSv4 offers between UNIX and non-UNIX clients. ZFS ACLs are similar to Windows NT-style ACLs, and provide more fine-grained access control than standard file permissions provide. ACLs are set and displayed with the chmod and ls commands.
The ACL model has two types of Access Control Entries (ACEs) that affect access checking: ALLOW and DENY. Therefore, you cannot infer from any single ACE that defines a set of permissions whether the permissions that are not defined in that ACE are allowed or denied.
For a description of the model, see the NFSv4 ACLs section of the acl(5) man page. For information about backup products, see Saving ZFS Data With Other Backup Products in Managing ZFS File Systems in Oracle Solaris 11.3.
You can assign and modify ACLs of the files and directories that you own. For files that others own, you must get permission in one of the following ways to assign and modify those ACLs:
The owner of the file or directory gave you the write_acl permission:
$ chmod A+user:jdoe:write_acl:f:allow file.1
You are assigned the Object Access Management rights profile. If you are not assigned a profile shell as your default shell, run the pfbash or pfexec command before running the command that changes the ACL.
You are assigned the root role.
ACLs have two basic formats:
Trivial ACL – Contains only entries for traditional UNIX user categories that are represented as owner@, group@, and everyone@.
For a newly created file, the default ACL grants owner@ all permissions, and prevents group@ and everyone@ from modifying the file and its attributes:
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@:/** same as group@ **/
For a newly created directory, the default ACL grants owner@ all permissions, and prevents group@ and everyone@ from modifying the directory and its attributes:
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@:/** same as group@ **/
Non-Trivial ACL – Contains entries for added user categories. The entries might also include inheritance flags, or are ordered in a non-traditional way.
A non-trivial entry is similar to the following example, which grants user jan specific permissions.
For a description of ACL access privileges, see the NFSv4 ACLs section of the acl(5) man page.
The following entry illustrates the elements that comprise an ACL entry. These elements apply to both trivial and non-trivial ACLs.
A number at the beginning of the entry, such as the number zero (0) in the example. The index identifies a specific entry and distinguishes the entry from others in the ACL.
The user category. In trivial ACLs, only entries for owner@, group@, and everyone@ are set. Non-trivial ACL entry types are user:username and group:groupname. In the example, the entry type is user:jan.
Permissions that are granted or denied to the entry type. In the example, the user is granted read_data and write_data.
An optional list of ACL flags that control how permissions are propagated in a directory structure. In the sample entry, file_inherit is also granted to the user.
Determines whether the permissions in an entry are allowed or denied. In the example, the permissions are allowed.
The following table describes each ACL entry type.
ZFS ACL sets are predefined combinations of ACL permissions. You cannot extend the sets.
full_set – All permissions
modify_set – All permissions except write_acl and write_owner
read_set – read_data, read_attributes, read_xattr, and read_acl
write_set – write_data, append_data, write_attributes, and write_xattr
You can apply an ACL set rather than separately setting individual permissions.Example 7 Applying an ACL Set to a File
With the addition of the read_set ACL set, the user jan can read file contents and the file's basic and extended attributes, and retain the default permissions.
$ pfexec chmod A+user:jan:read_set:allow file.1 $ ls -v file.1 -r--r--r--+ 1 root root 206695 Jul 20 13:43 file.1 0:user:jan:read_data/read_xattr/read_attributes/read_acl:allow ...
The ZFS file system includes two properties that affect ACLs:
aclmode – Modifies ACL behavior when a file is initially created or controls how an ACL is modified during a chmod operation.
By default, ACL entries are discarded. Other possible modes are a mask that reduces user or group permissions, and a passthrough that leaves the ACLs in effect.
For more information about aclmode values, see the aclmode entry in the zfs(1M) man page and Example 14, Showing the Effects of the aclmode and aclinherit Properties on ACL Permissions.
aclinherit – Determines the behavior of ACL inheritance and ACL interaction with chmod operations.
By default, write_owner and write_acl permissions are removed when an ACL entry is inherited. Other possible behaviors are to discard all ACL entries, only inherit deny entries, and leave the ACLs in effect with passthrough.
ACL inheritance enables a newly created file or directory to inherit the ACLs that it should inherit without disregarding the existing permission bits on the parent directory. By default, ACLs are not inherited. A non-trivial ACL on a directory is not inherited to any subsequent directory. You must specify the inheritance of an ACL on a file or directory.
ZFS and NFSv4 provide the following inheritance flags. The letters in parentheses are the compact format of the flag:
file_inherit (f) – Inherit from parent directory.
dir_inherit (d) – Inherit from parent directory.
inherit_only (i) – Newly created files or subdirectories inherit from the parent directory.
no_propagate (n) – Inherit only to the first level directory.
failed_access (F) – Alarm or audit record created at failed access.
successful_access (S) – Alarm or audit record created at successful access.
- – No permissions.
inherited (I) – Indicator of inheritance.
For a full description of the optional inheritance flags, see the NFSv4 ACLs section of the acl(5) man page.
In addition, you can change the default ACL inheritance policy on a file system by using the aclinherit file system property. For more information about this property, see ACL Properties and Setting ACL Inheritance on ZFS Files.