Shares - ACL Behavior
For information on ACLs and how they work, see the root directory ACL documentation.
ACL Behavior on Mode Change
When an ACL is modified via chmod(2) using the standard Unix user/group/other permissions, the
simplified mode change request will interact with the existing ACL in different ways depending on
the setting of this property.
Table 12-16 Mode Change Values
|
|
|
|
Discard ACL
|
discard
|
All ACL entries that do not represent the mode of the directory or file are discarded. This is
the default behavior.
|
|
Mask ACL with mode
|
mask
|
The permissions are reduced, such that they are no greater than the group permission bits,
unless it is a user entry that has the same UID as the owner of the file or directory. In this case,
the ACL permissions are reduced so that they are no greater than owner permission bits. The mask
value also preserves the ACL across mode changes, provided an explicit ACL set operation has not
been performed.
|
|
Do not change ACL
|
passthrough
|
No changes are made to the ACL other than generating the necessary ACL entries to represent
the new mode of the file or directory.
|
|
ACL Inheritance Behavior
When a new file or directory is created, it is possible to inherit existing ACL settings from
the parent directory. This property controls how this inheritance works. These property settings
usually only affect ACL entries that are flagged as inheritable - other entries are not propagated
regardless of this property setting. However, all trivial ACL entries are inheritable when used with
SMB. A trivial ACL represents the traditional Unix owner/group/other entries.
Table 12-17 ACL Inheritance Behavior Values
|
|
|
|
Do not inherit entries
|
discard
|
No ACL entries are inherited. The file or directory is created according to the client and
protocol being used.
|
|
Only inherit deny entries
|
noallow
|
Only inheritable ACL entries specifying "deny" permissions are inherited.
|
|
Inherit all but "write ACL" and "change owner"
|
restricted
|
Removes the "write_acl" and "write_owner" permissions when the ACL entry is inherited, but
otherwise leaves inheritable ACL entries untouched. This is the default.
|
|
Inherit all entries
|
passthrough
|
All inheritable ACL entries are inherited. The "passthrough" mode is typically used to cause
all "data" files to be created with an identical mode in a directory tree. An administrator sets up
ACL inheritance so that all files are created with a mode, such as 0664 or 0666.
|
|
Inherit all but "execute" when not specified
|
passthrough-x
|
Same as 'passthrough', except that the owner, group, and everyone ACL entries inherit the
execute permission only if the file creation mode also requests the execute bit. The "passthrough"
setting works as expected for data files, but you might want to optionally include the execute bit
from the file creation mode into the inherited ACL. One example is an output file that is generated
from tools, such as "cc" or "gcc". If the inherited ACL doesn't include the execute bit, then the
output executable from the compiler won't be executable until you use chmod(1) to change the file's
permissions.
|
|
When using SMB to create a file in a directory with a trivial ACL, all ACL entries are
inherited. As a result, the following behavior occurs:
-
Inheritance bits display differently when viewed in SMB or NFS. When viewing the ACL
directory in SMB, inheritance bits are displayed. In NFS, inheritance bits are not displayed.
-
When a file is created in a directory using SMB, its ACL entries are shown as inherited;
however, when viewed through NFS, the directory has no inheritable ACL entries.
-
If the ACL is changed so that it is no longer trivial, e.g., by adding an access control
entry (ACE), this behavior does not occur.
-
If the ACL is modified using SMB, the resulting ACL will have the previously synthetic
inheritance bits turned into real inheritance bits.
All of the above behavior is subject to change in a future release.
