I am sponsoring the following fasttrack for Mark Shellenbaum. This
case modifies the behavior of ZFS acls to improve the interoperability
story when ZFS file systems are shared using NFS and CIFS. The case
seeks micro/patch binding. Timeout is 2/2/2010.
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2010 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Improved ACL interoperability
1.2. Name of Document Author/Supplier:
Author: Mark Shellenbaum
1.3 Date of This Document:
26 January, 2010
4. Technical Description
Executive Summary:
This case changes the default behavior of ACLs for CIFS and NFS so that
it is easier to understand with *fewer* configuration knobs. The
new default behavior remains POSIX compliant and is more in line with
the expectation of CIFS users, local ZFS users, and NFS users. This
case does not introduce any changes that would cause files to have more
permissable access than the previous behavior.
Problems:
A number of issues have turned up with trying to do cross protocol (NFS/CIFS)
sharing of ZFS file systems.
- Deny ACES in standard trivial ACLs cause issues for
the Windows ACL GUI, which then results in ACLs being resorted
and the access to the file changed.
- ZFS computes a mode based on the presence of the owner@, group@ and
everyone@ ACES. The Solaris CIFS server usually creates files that
only have a user and group ACE and no owner@, group@ or everyone@ entries.
This is because Windows has no knowledge of owner@ and group@ ACEs. Those
are NFSv4 extensions. This results in files being created with a mode of
zero and that confuses customers.
- chmod(2) behavior under ZFS has caused a lot of confusion among customers.
ZFS tries to preserve ACLs during chmod(2) and this often causes the
ACL to change in a very non-intuitive way and results in a constant stream
of questions on multiple mailing lists. The chmod(2) behavior also
gives the Windows ACL GUI issues due to the insertion of deny ACEs.
Solutions:
- ZFS can create trivial ACLs that don't require deny ACEs for all but
unusual permissions. For example a mode of 0644, 0755, 0664 do not need
deny ACEs, but modes, such as 0705, 0060 and so on, will require deny ACEs.
Examples of the new layout are described later in this document.
- Inheritance changes. ZFS "splits" ACEs into multiple ACES during
inheritance
to try to preserve the original permission unmodified. It does this
by creating a "inherit_only" ACE. This has been a point of confusion with
customers who don't understand where the "inherit_only" ACE came from.
The solution is to stop doing the "splitting" operation and just modify
the permissions as necessary to enforce the mode of file create.
- The semantics of the "aclinherit" property will change to include
"trimming" down permissions when the property is set to "restricted".
The effect of this will be the same as what the old "aclmode" property would
do when set to "groupmask", except that it won't be doing the ACE splitting
described above.
- ZFS appears to be the only file system supporting NFSv4 ACLs
that attempts to preserve ACLs during chmod(2) operations. Unfortunately,
this requires the ACL to be modified in ways that are confusing to
customers and the time has come to stop the confusion and to just
"discard" the ACL during chmod(2) operations. This implies that the ZFS
aclmode property will no longer be needed and will be removed from ZFS.
- New mode calculation rules. If an ACL has a "user" ACE that is also the
file owner, then those permissions will be included in the computation
of the mode. The same is also true if a "group" ACE is the group owner
of the file.
New ACE Layout Examples
File with a mode of 0644:
-rw-r--r-- 1 root staff 5 Dec 9 13:18 file.1
owner@:rw-p--aARWcCos:-------:allow
group@:r-----a-R-c--s:-------:allow
everyone@:r-----a-R-c--s:-------:allow
File with a mode of 0777:
-rwxrwxrwx 1 root staff 5 Dec 9 13:18 file.1
owner@:rwxp--aARWcCos:-------:allow
group@:rwxp--a-R-c--s:-------:allow
everyone@:rwxp--a-R-c--s:-------:allow
File with a mode of 0466:
-r--rw-rw- 1 root staff 5 Dec 9 13:18 file.1
owner@:-w------------:-------:deny
owner@:r-----aARWcCos:-------:allow
group@:rw-p--a-R-c--s:-------:allow
everyone@:rw-p--a-R-c--s:-------:allow
Deny entry is required to prevent owner from picking up write
permission from the group@ or everyone@ entry.
File with a mode of 0447:
-r--r--rwx 1 root staff 5 Dec 9 13:18 file.1
owner@:-wx-----------:-------:deny
group@:-wx-----------:-------:deny
owner@:r-----aARWcCos:-------:allow
group@:r-----a-R-c--s:-------:allow
everyone@:rwxp--a-R-c--s:-------:allow
Deny entries are needed for both owner@ and group@ entries to prevent
the owner or group owner from picking up write/execute permission
from the everyone@ entry.
File with a mode of 0707:
-rwx---rwx 1 root staff 5 Dec 9 13:18 file.1
owner@:rwx-----------:-------:allow
group@:rwx-----------:-------:deny
owner@:rwxp--aARWcCos:-------:allow
group@:------a-R-c--s:-------:allow
everyone@:rwxp--a-R-c--s:-------:allow
The owner@ allow entry is needed to prevent the group@ deny entry
from taking the owners read/write/execute permission away.
ACE Inheritance
Parent directory has the following ACL:
drwxr-xr-x+ 2 root root 2 Dec 9 14:18 dir.1
user:marks:rwxp----------:fd-----:allow
owner@:rwxp--aARWcCos:-------:allow
group@:r-x---a-R-c--s:-------:allow
everyone@:r-x---a-R-c--s:-------:allow
A simple file create in directory dir.1 will result in the following
ACL:
# touch file.1
# ls -V file.1
-rw-r--r--+ 1 root root 0 Dec 9 14:20 file.1
user:marks:r-------------:------I:allow
owner@:rw-p--aARWcCos:-------:allow
group@:r-----a-R-c--s:-------:allow
everyone@:r-----a-R-c--s:-------:allow
The inherited ACE for marks was reduced to be no greater than the group
permissions because the "aclmode" property is set to "restricted."
If the "aclinherit" property was set to "passthrough" then the inherited
permissions for "marks" would have been "rwxp."
Now, lets create a directory.
# mkdir dir.2
# ls -dV dir.2
drwxr-xr-x+ 2 root root 2 Dec 9 14:21 dir.2
user:marks:r-x-----------:fd----I:allow
owner@:rwxp--aARWcCos:-------:allow
group@:r-x---a-R-c--s:-------:allow
everyone@:r-x---a-R-c--s:-------:allow
The inherited ACE for 'marks' was reduced to be no greater than
the group permissions because the "aclinherit" property is set to
"restricted."
With the aclinherit property set to passthrough the full ACE
permissions are inherited as follows:
# touch file.2
# ls -V file.2
-rw-r--r--+ 1 root root 0 Dec 9 14:24 file.2
user:marks:rwxp----------:------I:allow
owner@:rw-p--aARWcCos:-------:allow
group@:r-----a-R-c--s:-------:allow
everyone@:r-----a-R-c--s:-------:allow
Chmod Behavior
The new chmod behavior is to always "discard" the ACL and replace
it with a new ACL that represents the new mode as specified to the
chmod(2) syscall.
# ls -V file.2
-rw-r--r--+ 1 root root 0 Dec 9 14:24 file.2
user:marks:rwxp----------:------I:allow
owner@:rw-p--aARWcCos:-------:allow
group@:r-----a-R-c--s:-------:allow
everyone@:r-----a-R-c--s:-------:allow
# chmod 640 file.2
# ls -V file.2
-rw-r----- 1 root root 0 Dec 9 14:24 file.2
owner@:rw-p--aARWcCos:-------:allow
group@:r-----a-R-c--s:-------:allow
everyone@:------a-R-c--s:-------:allow
Mode Computation Example
-rwxr-----+ 1 marks staff 0 Dec 9 14:24 file.2
user:marks:rwxpdDaARWcCos:-------:allow
group:staff:r-----a-R-c---:-------:allow
The mode in this example is 740 because the user "marks" is the owner
of the file and "marks" is also a member of group staff. Previously,
only owner@, group@ or everyone@ are considered in the mode
computation, but if a "user" or "group" ACE is the file owner or file
group owner then those will be used in additional to the owner@,
group@ and everyone@ entries.
Man Page diffs
0,58d39
<
< aclmode=discard | groupmask | passthrough
<
< Controls how an ACL is modified during chmod(2). A file
< system with an aclmode property of discard deletes all
< ACL entries that do not represent the mode of the file.
< An aclmode property of groupmask (the default) reduces
< user or group permissions. 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. A file system with an
< aclmode property of passthrough indicates that no
< changes are made to the ACL other than generating the
< necessary ACL entries to represent the new mode of the
< file or directory.
<
<
2056d2036
< aclmode property
2374d2353
< pool/home/bob aclmode groupmask default
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
