- Joined
- Mar 6, 2014
- Messages
- 9,553
This is a technical explanation of the ACL changes that affected several users after upgrading to 11.2-U2. I apologize for any inconvenience caused by the upgrade. We will shortly issue an update reverting the change (as well as fixing a few other bugs that crept into the release).
Overview of a ZFS ACE:
ACL resulting from chmod 777:
The bottom three lines not prefixed by the
The crux of the problem is that when zfsacl is enabled, samba looks at all of these bits to determine what a user can and can't do. This can cause interesting permissions issues (for instance A (write attributes) and W(write extended attributes) are missing from the group@ and everyone@ entries. These are required for "basic write" permissions in an NTFS ACL.
Per RFC7350 for NFS4 (https://tools.ietf.org/html/rfc7530#section-6.2.1.3.2), vfs_zfsacl was originally granting "delete child" on directories in case ACE4_ADD_FILE, (which shares a bitmask constant with ACE4_WRITE_DATA) was set. This is what allowed delete in the above case. It also means that when a Windows Admin tries to grant the following basic permissions: "Read & execute", "List folder contents", "Read", Write". The permissions editor also shows "special permissions" checked and "delete subfolders and files" has been automatically granted (although the underlying filesystem permissions are set correctly). This also means that the next operation that sets an ACL on that file will change the underlying ZFS ACL to reflect what samba is telling the SMB client (i.e. setting delete_child). This means that we cannot replicate NTFS ACL behavior. A key example of this is that we are unable to create a write-only dropbox without adding explicit "deny" aces.
The reason why only some users are negatively affected by this change.
Unaffected:
- Users who selected "Windows" ACL type for the SMB share (which is the supported method of configuring SMB shares).
- Users who have used an SMB client (such as Windows) to control changes to their ACLs.
Affected:
- Users who have set "Unix" permissions type for the SMB share.
- Users who have set the ZFS aclmode to "passthrough" then executed chmod on the SMB share.
So where do we go from here? In U3 we will revert the changes to zfsacl. Original behavior will be restored, but the new behavior will ultimately be brought into ixnas because we want to reproduce Windows ACL behavior as closely as possible (probably U3).
Overview of a ZFS ACE:
Code:
everyone@:rwxpDdaARWcCos:-------:allow ||||||||||||||:||||||| (r)read data +|||||||||||||:||||||+ (I)nherited (w)rite data -+||||||||||||:|||||+- (F)ailed access (audit) e(x)ecute --+|||||||||||:||||+-- (S)uccess access (audit) a(p)pend ---+||||||||||:|||+--- (n)o propagate (d)elete ----+|||||||||:||+---- (i)nherit only (D)elete child -----+||||||||:|+----- (d)irectory inherit read (a)ttrib ------+|||||||:+------ (f)ile inherit write (A)ttrib -------+|||||| (R)ead xattr --------+||||| (W)rite xattr ---------+|||| read a(c)l ----------+||| write a(C)l -----------+|| change (o)wner ------------+|
ACL resulting from chmod 777:
Code:
# file: test # owner: minio # group: minio owner@:rwxp--aARWcCos:-------:allow group@:rwxp--a-R-c--s:-------:allow everyone@:rwxp--a-R-c--s:-------:allow
The bottom three lines not prefixed by the
#
symbol are basically the output of acl_to_text(). Note that there are two dashes between (p) append and (a) read attributes. These are "delete" and "delete child". "delete child" means permission to delete files or folders inside a directory. If we directly translate the above ACL to an NTFS ACL, then no one has the ability to delete files (or rename them).The crux of the problem is that when zfsacl is enabled, samba looks at all of these bits to determine what a user can and can't do. This can cause interesting permissions issues (for instance A (write attributes) and W(write extended attributes) are missing from the group@ and everyone@ entries. These are required for "basic write" permissions in an NTFS ACL.
Per RFC7350 for NFS4 (https://tools.ietf.org/html/rfc7530#section-6.2.1.3.2), vfs_zfsacl was originally granting "delete child" on directories in case ACE4_ADD_FILE, (which shares a bitmask constant with ACE4_WRITE_DATA) was set. This is what allowed delete in the above case. It also means that when a Windows Admin tries to grant the following basic permissions: "Read & execute", "List folder contents", "Read", Write". The permissions editor also shows "special permissions" checked and "delete subfolders and files" has been automatically granted (although the underlying filesystem permissions are set correctly). This also means that the next operation that sets an ACL on that file will change the underlying ZFS ACL to reflect what samba is telling the SMB client (i.e. setting delete_child). This means that we cannot replicate NTFS ACL behavior. A key example of this is that we are unable to create a write-only dropbox without adding explicit "deny" aces.
The reason why only some users are negatively affected by this change.
Unaffected:
- Users who selected "Windows" ACL type for the SMB share (which is the supported method of configuring SMB shares).
- Users who have used an SMB client (such as Windows) to control changes to their ACLs.
Affected:
- Users who have set "Unix" permissions type for the SMB share.
- Users who have set the ZFS aclmode to "passthrough" then executed chmod on the SMB share.
So where do we go from here? In U3 we will revert the changes to zfsacl. Original behavior will be restored, but the new behavior will ultimately be brought into ixnas because we want to reproduce Windows ACL behavior as closely as possible (probably U3).