zfsacl in 11.2-U2

[anodos]

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:

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

 

[KrisBee]

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

What does this mean for people who are already, and want to continue, using UNIX perms of SMB shared datasets accessed via linux or macOS?
Your statement does not make it clear if zfsacl is it to be superseded by ixnas or when as you've referred to U3 in two different contexts.

 

[anodos]

What does this mean for people who are already, and want to continue, using UNIX perms of SMB shared datasets accessed via linux or macOS?
Your statement does not make it clear if zfsacl is it to be superseded by ixnas or when as you've referred to U3 in two different contexts.

zfsacl will remain as it is in 11.2-U1. There will be no further changes to it. ixnas will eventually become the default for new shares (probably 11.3), but zfsacl will still always be an option.
Big picture, we need a GUI ACL editor.

 

[KrisBee]

zfsacl will remain as it is in 11.2-U1. There will be no further changes to it. ixnas will eventually become the default for new shares (probably 11.3), but zfsacl will still always be an option.
Big picture, we need a GUI ACL editor.

Appreciate the clarification and explanation of the problem in your first post.

 

[seanm]

Big picture, we need a GUI ACL editor

Yeah, that'd be nice for macOS users, where SMB is the default sharing type (these days). Is there a ticket I could CC myself on for "we need a GUI ACL editor"? Would it be this? https://redmine.ixsystems.com/issues/23398

 

[anodos]

Yeah, that'd be nice for macOS users, where SMB is the default sharing type (these days). Is there a ticket I could CC myself on for "we need a GUI ACL editor"? Would it be this? https://redmine.ixsystems.com/issues/23398

That's probably a good place to start. I know this is somewhat ugly, but if you need to set ACLs recursively in the current release, you can use setfacl to set the ACL at the root of a share, the run winacl -a clone -r -p /path/to/share This will take the ACL that you just set and push it recursively on all files and directories. It's pretty fast and efficient. It basically calls acl_get_file() to get the target acl, then uses fts to recurse and set it on the files underneath.