Sun ZFS Storage 7420
 
Oracle ZFS Storage ZS5-2
 
Sun Storage 7110 Unified Storage System
 
Oracle ZFS Storage ZS3-2
 
Sun Storage 7210 Unified Storage System
 
Oracle ZFS Storage ZS4-4
 
Sun Storage 7410 Unified Storage System
 
Oracle ZFS Storage ZS5-4
 
Sun Storage 7310 Unified Storage System
 
Sun ZFS Storage 7120
 
Oracle ZFS Storage ZS3-4
 
Sun ZFS Storage 7320
 
Oracle ZFS Storage ZS3-BA
 

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

In this Document

Goal

Solution

Traditional UNIX permissions:

ZFS/SMB ACL permissions:

ACL Behavior on Mode Change:

ACL Inheritance Behavior

References

Created from <SR 3-3740498461>

Applies to:

Goal

This document provides some guidance on configuring file and directory permissions for shared access from both SMB and NFS.

Solution

Careful planning is required to successfully configure permissions for multi-protocol access. There are significant differences between traditional UNIX permissions and the newer ACL model. Here is a brief overview of the two security models:

Traditional UNIX permissions:

The basic UNIX file permissions expressed as a three digit octal number. The three digits represent the permissions for owner, group and world respectively.

ZFS/SMB ACL permissions:

Access Control List. Fourteen bits, each providing a specific permission, and four more for inheritance. These allow very granular and fine access control compared to traditional UNIX permissions. For example, there are four different types of read permissions: read data, read attribute, read extended attributes and read ACL.

In addition to the extended permissions, named users and groups can be added, which allows us to grant access to others besides owner, group and world.

Here is an example of a complex ACL:

NFSv3 clients are not capable of understanding these or setting these, but they can preserve them if configured to do so. This is done at the Shares/Access screen in the BUI in the ACL Behavior pulldown menus:

The relevant settings for each of these are as follows:

ACL Behavior on Mode Change:

• Discard ACL -- 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 -- 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 -- No changes are made to the ACL other than generating the necessary ACL entries to represent the new mode of the file or directory.

Any of these three settings can be useful, depending on the plans to allow mode changes. The "discard" option is relatively "safe" for environments that use NFSv3 clients as a primary means to set security, as things like chmod 700 work as they always have, rather than preserving ACLs that could allow unexpected access to files after that operation.

ACL Inheritance Behavior

• 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.

Given the difference in these models, it is a good idea to pick one as primary for a given data set, though that choice may vary from filesystem to filesystem, or even directory to directory. The considerations for making this choice are primarily the clients that will be accessing the data, and the clients that will be setting security for each of the file structures.

NFSv3 clients cannot set or interpret the extended ACL security. However, every file and directory effectively has both permission sets. ACL permissions are present on every file, and the traditional permissions are synthesized from the ACL. In the example below, we have 755, which means in this case, user 'joe' can write and everyone else can only read.

The security model is designed so that if you grant standard file permissions from one model, they translate to the other. So, if you issue a chmod 755, it will produce the three entries in the ACL that you would expect; full permissions for the owner, read and execute for the group and everyone. The inverse is also true, if you grant owner, group or world read, write or execute permissions, these will be reflected in the traditional permission bits. Of course, one of the identity mapping policies would be used to map 'joe' and 'staff' to a Windows user and group so that these permissions would be meaningful on the other side.

Here is an example of a system set to ACL Behavior on Mode Change = Discard

We'll use the complex ACL from the beginning of this article as an example:

This ACL uses named groups and users, inheritance bits, and bits that go beyond what the octal permissions can convey. Note the "+" character at the end of the mode bits:(drwxrwxr--+)
This is an indication that there's more in the ACL than a simple octal mode can represent. Next we'll run a mode change:

... we can see that much of the detail of the ACL has been lost in the conversion. All the named users, named groups and inheritance bits are gone. Also note that the "+" character is no longer present at the end of the mode bits. This is an indication that the ACL is an exact match for an octal permission set, in this case 755. This ACL is known as a trivial ACL.

So, given the points above, in order to use the traditional UNIX security model for a data set:

• Don't assign permissions to entities other than owner, group or world
• Don't rely on inheritance bits
• Keep in mind that there are only three slots to define access permissions.

... and in order to use the ACL model:

• Don't allow NFSv3 users to set file or directory permissions, or choose a setting that preserves ACL data..
• Ensure that NFSv4 users exclusively use the ACL-specific chmod commands.
• Always set the standard "fd" (file and directory) inheritance bits on directories that will be written to from Windows.
• When applying security from Windows, use only Access Control entries for users and groups that have valid mappings to UNIX users and groups.

Back to Document 1428753.1 - Sun Storage 7000 Unified Storage System: How to Troubleshoot Identity Mapping and cross-platform file sharing issues.

References

This solution has no attachment