please see the 5652
Created attachment 3447 [details] options added to zfsacl module controling the ordering of the ACEs The following module options to the source/modules/vfs_zfsacl.c was added: addressing prefix: "vfszfsacl:" option name: "acesort" settings: "dontcare", "ntfs" ("ntfs" is default) effect: when the ZFS/NFSv4 ACL is converted into the NTFS ACL if "dontcare" is set it leaving the ACEs in ACL as nor where "ntfs" is set conversion is placing the deny ACEs before the other ACE types in ACL and also does not placing the zero-mask ACEs into the NTFS ACL
"ntfs ordering": BAD HACK - BAD IDEA - not required - see 5652
Is there any reason not to add this patch to samba? In testing viability of using zfs acls I'm now running into the ace ordering error messages and it is quite distracting for our users.
ACL reordering changes semantics. Samba should never change ACL semantics on the way from disk to client. Volker
does not ordering the "deny" ACEs fist can lead to serious security issue as discussed on #5652
Created attachment 4014 [details] (f)chmod() acmm blocking on ZFS This patch adds blocking of the (f)chmod() calls on the ZFS. chmod() call is returning the siles on ZFS back under the POSIX control. It does mean the 6 special ACEs is added into the ACL making it unusable under Windows (NTFS does not require POSIX. Possibility of sorting of the ACEs in ACL from the previous diff is left but its default behavior is turned to "dontcare". It can workaround the problem of the warning messages in Win Explorer on shares running on older zpool releases does not supporting the "aclmode=passthrough" property (zpools created on Solaris Nevada builds < 88 or Solaris 10 update 5 and below which can not be zpool-upgraded for some reasons).
Attached diff was tested on Solaris Nevada b110 with samba-3.0.34 . Problem is fixed by the blocking of the (f)chmod() call on ZFS.
ACL sorting can induce another problems. One for anothers is: ZFS is adding the "everyone@:W::deny" rule into the ACL by default. So if such rule is reordered to take place before any "allow" rule without removing the "W"-flag manually all "Extended File Attributes" can not be write-accessed by "everyone@" ...it means really by everyone even by file owner. If the samba (S)-option "ea support = yes" is set and smbd can not write the Extended File Attributes the DOS-attributes are written into the POSIX-mask instead (doing chmod()) in this case. chmod()-call will cause the POSIX-mask is transformed into the 6 special-ACEs added to the end of the ACL of the file. ...such nice case of the circular dependencies is called "perpetuum debile" in Czech nerd's slang :-) Bug is better to be closed and no one of the proposed attachments should rather be applied. Here is no programmatic way to automatize such task faultlessly. Documentation issue should be raised instead. Users migrating to ZFS are usually surprised by the number of parameters to control to setup the samba share there and their effort can fail too simply.
Jiri, can you tell us how the in-kernel cifs does it? Volker
CIFS kernel is running above the "idmap" service. "idmap" is mapping the SIDs to ephemeral uid/gid-s (uid/gid > 2G). Such mapping is not permanent by default so the mapping tuples (A_OWNERSID, A_GROUPSID) are stored via the getattrat/setattrat (fgetattr(3C)) interface as XDR-encoded packed nvlists. i.e. the dirs and files can associated info in "Extended File Attributes": -bash-3.2# runat /samba/homes/barbusin/ ls -l total 2 -r--r--r-- 1 root root 84 Apr 10 18:57 SUNWattr_ro -rw-r--r-- 1 root root 408 Apr 10 18:57 SUNWattr_rw -bash-3.2# runat /samba/homes/barbusin/hi.txt ls -l total 3 -r--r--r-- 1 root root 84 Apr 14 12:47 SUNWattr_ro -rw-r--r-- 1 root root 408 Apr 14 12:47 SUNWattr_rw -rw-rw---- 1 SMBSETUP\barbucha SMBSETUP\domain users 4 Apr 14 12:47 user.DOSATTRIB ... SUNWattr_r? "Extended File Attributes" are storing such info. For better understand-ability I have listed the file created by samba having the "ea support = yes" set to see the "File Extended Attributes" set by samba (DOS-flags on file). acl(2) interface can contain also info about the file owner is determined by the SID (see: ACL_SID_FMT -formating option in /usr/include/sys/acl.h) but this interface is evolving.
That's not what I really am interested in. How does the in-kernel CIFS solve the ACL ordering issue? :-) Volker
Jiri, can you tell how the cifs in-kernel server manages the NFS4 ACL ordering issue?
Solaris SMB do not use NFSv4 ACLs but stores own NTFS ACLs (managed via SMB) into B-trees in Ext.Attrs. so each directory member has at least 2 files in Ext.Attrs.: # runat /usr/ 'ls -al' total 4 drwxrwxrwt 4 root sys 4 Feb 3 23:24 . drwxr-xr-x 38 root sys 50 Feb 3 23:24 .. -r--r--r-- 1 root root 156 Feb 3 23:24 SUNWattr_ro -rw-r--r-- 1 root root 508 Feb 3 23:24 SUNWattr_rw where those structures are stored. I also tried to ask if there is interoperability with these ACLs (SMB, NFSv4) on files shared by both methods but I have already received answer for something else so I do not know such details. Samba (as SMB server running in user-land) can re-share NFSv4 mount so exact implementation of the ACLs is relevant.
*** Bug 5652 has been marked as a duplicate of this bug. ***
reopening because this bug was closed only because Jiri attached a patch here. In Samba it's not fixed though. It's also a generic issue for other NF4 ACL supporting filesystems, most of them drop the NFS4 ACLs if a chmod() call is being done. We might want to add a generic nfs4:chmod = [yes|no] option (we have the generic nfs4:chown equivalent already).