Improved ACL interoperability [PSARC/2010/029 FastTrack timeout 02/02/2010]
This case was approved in today's meeting. -tim
Improved ACL interoperability [PSARC/2010/029 FastTrack timeout 02/02/2010]
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
Improved ACL interoperability [PSARC/2010/029 FastTrack timeout 02/02/2010]
This all makes perfect sense to me and will assist user understanding and interoperability. I think the only real visible change for most people is that chmod(2) with traditional unix perms will remove the ACL. That might be surprising in some cases, but I can't at the current time think of any applications that would depend on using chmod(2) while preserving an ACL - since most apps don't know about ACLs and most apps (rather than code system utils) don't call chmod(2). So I'm happy with this and it gets my +1. -- Darren J Moffat
Improved ACL interoperability [PSARC/2010/029 FastTrack timeout 02/02/2010]
Tim Haley wrote: 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. Just to confirm, the examples above are the same regardless of whether or not the owner is a member of the group, right? [Even if the owner is not a group member at the time that the ACE's are created, he could be in the future.] Scott -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278)
Improved ACL interoperability [PSARC/2010/029 FastTrack timeout 02/02/2010]
Presumably in aclinherit=passthrough-x mode if the new ACL has no @owner/@group ACEs but has ACEs for the file's owner/group then the requested mode_t will be applied to those ACEs? Or is aclinherit=passthrough-x mode left unchanged? Nico --
Improved ACL interoperability [PSARC/2010/029 FastTrack timeout 02/02/2010]
On Jan 26, 2010, at 9:19 AM, Tim Haley wrote: ... 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. A nit: aclmode in the text quoted above should be aclinherit, right? -- Glenn
Improved ACL interoperability [PSARC/2010/029 FastTrack timeout 02/02/2010]
On Jan 26, 2010, at 9:19 AM, Tim Haley wrote: ... 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. A nit: aclmode in the text quoted above should be aclinherit, right? Yes, that should have been aclinherit -- Glenn ___ opensolaris-arc mailing list opensolaris-arc at opensolaris.org -- This message posted from opensolaris.org
Improved ACL interoperability [PSARC/2010/029 FastTrack timeout 02/02/2010]
On 01/26/10 12:46 PM, Scott Rotondo wrote: Tim Haley wrote: 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. Just to confirm, the examples above are the same regardless of whether or not the owner is a member of the group, right? [Even if the owner is not a group member at the time that the ACE's are created, he could be in the future.] Yes Scott
