Asset ID: |
1-71-1428773.1 |
Update Date: | 2012-06-28 |
Keywords: | |
Solution Type
Technical Instruction Sure
Solution
1428773.1
:
Sun Storage 7000 Unified Storage System: Configuring file and directory permissions for shared access between UNIX and Windows clients.
Related Items |
- Sun Storage 7410 Unified Storage System
- Sun Storage 7310 Unified Storage System
- Sun ZFS Storage 7120
- Sun Storage 7110 Unified Storage System
- Sun ZFS Storage 7320
- Sun ZFS Storage 7420
- Sun Storage 7210 Unified Storage System
|
Related Categories |
- PLA-Support>Sun Systems>DISK>NAS>SN-DK: 7xxx NAS
- .Old GCS Categories>Sun Microsystems>Storage - Disk>Unified Storage
|
In this Document
Created from <SR 3-3740498461>
Applies to:
Sun Storage 7210 Unified Storage System - Version Not Applicable to Not Applicable [Release N/A]
Sun Storage 7410 Unified Storage System - Version Not Applicable to Not Applicable [Release N/A]
Sun Storage 7110 Unified Storage System - Version Not Applicable to Not Applicable [Release N/A]
Sun ZFS Storage 7120 - Version Not Applicable to Not Applicable [Release N/A]
Sun ZFS Storage 7320 - Version Not Applicable to Not Applicable [Release N/A]
7000 Appliance OS (Fishworks)
Goal
This document provides some guidance on configuring file and directory permissions for shared access from both SMB and NFS.
Fix
Note: This document assumes that you are running software version 2010.8.17.4.0 or later. There are a number of important ACL and permission-related enhancements in this version and it is STRONGLY recommended that you upgrade to at least this version in order to successfully share files between UNIX and Windows.
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.
Example:
nas1# ls -l home
total 4
drwxr-xr-x 2 root root 2 Aug 24 11:51 file1
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:
ar-nas-4a# ls -Vd eye
drwxrwxr--+ 3 joe staff 10 Oct 25 20:08 eye
group:2147483653:rwxpdDaARWc--s:fd-----:allow
user:2147483650:r-----a-R-c---:fd-----:allow
owner@:rwxpdDaARWcCos:fd-----:allow
group@:rwxpdDaARWc--s:f------:allow
group@:r-----a-R-c---:-d-----:allow
everyone@:r-----a-R-c---:-------:allow
Tip: use ls -V from Solaris to display all the permission bits and line them up nicely for comparison.
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:

Note: The ACL Behavior on Mode Change is only present on system software version 2011.1 and newer (with the exception of very old code that is beyond the scope of this document). If you are running 2010.Q3 code, you will not see the ACL Behavior on Mode Change pulldown menu, and all shares will behave as listed below under "Discard ACL".
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.
A "mode change" is a non-ACL aware security change, i.e. a chmod-type change to the mode of the file. This could be an actual "chmod ####" command, or it could be something more subtle, like a file rewritten with the vim utility. In any case, this setting specifies what will be done in the case of a security modification that is not ACL aware. The setting is applied globally to every file and directory in the share.
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:
ar-nas-4a# ls -Vd eye
drwxrwxr--+ 3 joe staff 10 Oct 25 20:08 eye
group:2147483653:rwxpdDaARWc--s:fd-----:allow
user:2147483650:r-----a-R-c---:fd-----:allow
owner@:rwxpdDaARWcCos:fd-----:allow
group@:rwxpdDaARWc--s:f------:allow
group@:r-----a-R-c---:-d-----:allow
everyone@:r-----a-R-c---:-------:allow
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:
nas4> chmod 755 eye
drwxr-xr-x 3 joe staff 10 Feb 1 00:05 eye
owner@:rwxp-DaARWcCos:-------:allow
group@:r-x---a-R-c--s:-------:allow
everyone@:r-x---a-R-c--s:-------:allow
... 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-pllatform file sharing issues.
References
<NOTE:1428753.1> - Sun Storage 7000 Unified Storage System: How to Troubleshoot Identity Mapping and cross-platform file sharing issues
Attachments
This solution has no attachment