Root Directory ACL

Fine-grained access on files and directories is managed via Access Control Lists. An ACL describes which permissions are granted, if any, to specific users or groups. Oracle ZFS Storage Appliance supports NFSv4.0 and NFSv4.1-style ACLs, also accessible over SMB. POSIX draft ACLs (used by NFSv3) are not supported. Some trivial ACLs can be represented over NFSv3, but making complicated ACL changes may result in undefined behavior when accessed over NFSv3.

Like root directory access, this property only affects the root directory of the filesystem. ACLs can be controlled through in-band protocol management; BUI and CLI provide a way to set the ACL just for the root directory of the filesystem. You can use in-band management tools if the BUI is not an option. Changing this ACL does not affect existing files and directories in the filesystem. Depending on the ACL inheritance behavior, these settings may or may not be inherited by newly created files and directories. However, all ACL entries are inherited when SMB is used to create a file in a directory with a trivial ACL.

An ACL is composed of any number of ACEs (access control entries). Each ACE describes a type/target, a set of permissions, inheritance flags and a type. ACEs are applied in order, starting at the beginning of the ACL, to determine whether a given action should be permitted. For information on in-band configuration ACLs through data protocols, consult the appropriate client documentation. The BUI interface for managing ACLs and the effect on the root directory are described here.

Table 4-63 Share - ACL Types

Type	Description
Owner	Current owner of the directory. If the owner is changed, this ACE will apply to the new owner.
Group	Current group of the directory. If the group is changed, this ACE will apply to the new group.
Everyone	Any user.
Named User	User named by the target field. The user can be specified as a user ID or a name resolvable by the current name service configuration.
Named Group	Group named by the target field. The group can be specified as a group ID or a name resolvable by the current name service configuration.

Table 4-64 Share - ACE Types

ACE Type	Description
Allow	The permissions are explicitly granted to the ACE target.
Deny	The permissions are explicitly denied to the ACE target.
Audit	Generates an audit record based on the permissions field. As with the Allow and Deny ACE types, the action is a success (S) or a failure (F). Because this ACL is only for the filesystem root directory, the inheritance is usually set to file and directory. Audit records are sent via the Syslog Relay service. To send audit events to a remote target, set audit class option Per File Audit (PerFileAudit). See Syslog Configuration.

Table 4-65 Share - ACL Permissions

Permission	Description
(r) Read Data/List Directory	Permission to list the contents of a directory. When inherited by a file, permission to read the data of the file.
(x) Execute File/Traverse Directory	Permission to traverse (lookup) entries in a directory. When inherited by a file, permission to execute the file.
(a) Read Attributes	Permission to read basic attributes (non-ACLs) of a file. Basic attributes are considered to be the stat level attributes, and allowing this permission means that the user can execute ls and stat equivalents.
(R) Read Extended Attributes	Permission to read the extended attributes of a file or do a lookup in the extended attributes directory.
(w) Write Data/Add File	Permission to add a new file to a directory. When inherited by a file, permission to modify a file's data anywhere in the file's offset range. This include the ability to grow the file or write to any arbitrary offset.
(p) Append Data/Add Subdirectory	Permission to create a subdirectory within a directory. When inherited by a file, permission to modify the file's data, but only starting at the end of the file. This permission (when applied to files) is not currently supported.
(d) Delete	Permission to delete a file.
(D) Delete Child	Permission to delete a file within a directory. As of the 2011.1 software release, if the sticky bit is set, a child file can only be deleted by the file owner.
(A) Write Attributes	Permission to change the times associated with a file or directory.
(W) Write Extended Attributes	Permission to create extended attributes or write to the extended attributes directory.
(c) Read ACL/Permissions	Permission to read the ACL.
(C) Write ACL/Permissions	Permission to write the ACL or change the basic access types.
(o) Change Owner	Permission to change the owner.
(f) Apply to Files	Inherit to all newly created files in a directory.
(d) Apply to Directories	Inherit to all newly created directories in a directory.
(i) Do not apply to self	The current ACE is not applied to the current directory, but does apply to children. This flag requires one of Apply to Files or Apply to Directories to be set.
(n) Do not apply past children	The current ACE should only be inherited one level of the tree, to immediate children. This flag requires one of Apply to Files or Apply to Directories to be set.

When the option to use Windows default permissions is used at share creation time, an ACL with the following three entries is created for the share's root directory:

Table 4-66 Share Root Directory Entities

Type	Action	Access
Owner	Allow	Full Control
Group	Allow	Read and Execute
Everyone	Allow	Read and Execute

In the CLI, set the root directory ACL properties after navigating to the shares context and selecting a project and filesystem. Use colons to separate the ACE properties, and separate multiple ACE entries with commas. The target and inheritance fields are optional. To set the properties, enter set root_acl=ace1,ace2,ace3,..., where acen is:

type:[target:]permissions:[inheritance:]type

Examples:

• set root_acl=owner@:r:allow
• set root_acl=everyone@:rwx:fd:allow
• set root_acl=user:root:r:allow