Sun Storage 7410 Unified Storage System
 
Sun Storage 7310 Unified Storage System
 
Sun ZFS Storage 7120
 
Sun ZFS Storage 7420
 
Sun ZFS Storage 7320
 
Sun Storage 7110 Unified Storage System
 
Sun Storage 7210 Unified Storage System
 

PLA-Support>Sun Systems>DISK>NAS>SN-DK: 7xxx NAS
 
.Old GCS Categories>Sun Microsystems>Storage - Disk>Unified Storage
 

In this Document

Goal

Fix

Created from <SR 3-3740498461>

Applies to:

Goal

This document explains file and directory inheritance on the ZFS Storage Appliance.

Fix

The inheritance bits in the ACL control how new files and directories inherit security. These bits can be found in the ls -V ACL display immediately following the security bits.

These bits are as follows:

(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 or both of the (f) and (d) bits 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 or both of the (f) and (d) bits to be set.

The first two are by far the most commonly used. For the purpose of this document, those two will be in the focus. The following example, have applied each combination of the (f) and (d) bits, and then list the results with ls -V:

Simply put, if the (f) bit is set for a given Access Control Entry, new files created in this directory will inherit that entry. If the (d) bit is set, new directories created in this directory will inherit that entry.

In the above example, the permissions on a directory was listed, then a directory was created and a file therein. The newly created directory picked up the two ACEs with the (d) bit set. It also picked up the one with the (f) bit set, though it sets the (i) "inherit only" bit in this case. This allows that entry to be passed on to newly created files in this child directory, though the (i) bit means they will not be applied to the directory itself.

The new file only picked up the entries with the (f) bit set, and did not pick up the inheritance bits as they are only meaningful on directories for obvious reasons.

Note that the last ACE in the original directory did not inherit at all, and was therefore only applied at that level.

One common use of this feature is to allow directories to inherit an execute bit while preventing it from propagating to files.



ACL Inheritance Behavior

There is also another setting that can affect inheritance, this is found on the Access tab of the share. It can be configured in any of the following ways. For most configurations, and especially those with Windows clients, the "Inherit all Entries" is recommended. Here is the complete list:

• Inherit all Entries -- Windows expects all files, with a few exceptions, to have inheritance bits set. In any environment with Windows clients present, you should use this setting to avoid compatibility issues.

• Do not inherit entries -- No ACL entries are inherited. The file or directory is created according to the client and protocol being used.

• Only inherit deny entries -- Only inheritable ACL entries specifying "deny" permissions are inherited.

• Inherit all but "write ACL" and "change owner" -- 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 -- 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 -- 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 it might be wanted 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 chmod(1) is used to change the file's permissions.

This solution has no attachment