ZFS on solaris order the ACEs in ACL in the following order by default: # ls -dV /samba/public/juraskovo/ drwxr-xr-x 2 SMBSETUP\jurasek SMBSETUP\domain users 2 Jul 30 20:05 /samba/public/juraskovo/ owner@:--------------:-------:deny owner@:rwxp---A-W-Co-:-------:allow group@:-w-p----------:-------:deny group@:r-x-----------:-------:allow everyone@:-w-p---A-W-Co-:-------:deny everyone@:r-x---a-R-c--s:-------:allow Where the NTFS requires the "deny" ACEs to be placed before the any other ACEs and the zero-mask ACEs should be avoided from the list. File which is created on the samba share has the ACL set to this ZFS defaults. This causes the warning message is displayed when the ACL editor is started on the GUI.
Can anyone please to submit the 5653 proposed diff into the source/modules/vfs_zfsacl.c module in samba 3.2 GPLv3 licensed binaries are not approved to be bundled with the Solaris yet so I did not also tested these changes in the samba 3.2 yet Thank you in advance Jiri
ACK: I have noticed the same behavior. But is this really a bug? If proper NT-style ACLs are being created once, inheritance can be used to provide default ACLs for newly created dirs and files, so I personally think this is not a bug, but rather a matter of how to set up the Samba/ZFS environment. At any rate, I would recommend to set aclinherit=passthrough and aclmode=passthrough on ZFS file systems used with Samba and NT ACL support to make ZFS not interfer with ACLs set by NT clients.
Your assumption is wrong. According to http://msdn.microsoft.com/en-us/library/aa446683%28VS.85%29.aspx Win processes sd ACEs in the same order as they occure (as ZFS does IIRC)! It doesn't expect to have all deny entries in front at all. It just __prefers__ to put all deny entries in front (see http://msdn.microsoft.com/en-us/library/aa379298%28VS.85%29.aspx) So explicit ACL ordering as proposed in 5653 should be considered a BAD HACK, which will definitely break stuff.
The problem is the "Warning Message" telling some ACE can be ineffective in case the "deny" ACEs are not precedes the other ACE. Ordering the ACEs as they are expected (deny first) you will suppress this message. In case of the "naive" processing of the ACEs by "first match" algorithm you can also fall into the serious security issue in case of the "deny" ACE is preceded by the "allow" ACE canceling its effect!!!
Jiri, I don't understand your comment about naive ACL processing. Could you please elaborate? I believe Samba ACL processing has be come as close as possible to O/S ACL processing, otherwise ACL semantics for smb/samba access and direct or NFS access will differ - and break interoperability. So my understanding is that we need to do whatever processing the underlying O/S scheme dictates, which, in the case of ZFS ACLs, is first accept match, IIRC. On the other hand, if an ACL can be reordered with semantic equivalence, I don't see why it shouldn't be.
I wrote: > So my understanding is that we need to do whatever processing the underlying > O/S scheme dictates, which, in the case of ZFS ACLs, is first accept match, ^^^^^^^^^^^^ Sorry for that glitch. "first match" is what I meant.
Jiri, I understand your concerns about a tool, which does not give you the control you need or produces misleading messages (windows rules)/reflects the capabilties of the underlying filesystem. However, that problem needs to be fixed by the tool vendor, not the fs implementation/layer. I think I don't need to go into deeper details... Your approach might work in a windows only environment, i.e. no one else except samba accesses the shared fs. As soon as you have a mixed environment, ordering breaks "everything". E.g. usually workgroup members have 770 umasks set, and thus "nfs/unix based work" usually produced/produces 0770 dir perms and 0660 file perms: drwxrwx--- 2 auser agroup 3 Mar 8 21:33 . -rw-rw---- 1 auser agroup 0 Mar 8 21:33 file and ZFS defaults to transform it to: drwxrwx--- 2 auser agroup 3 Mar 8 21:33 . owner@:--------------:-------:deny owner@:rwxp---A-W-Co-:-------:allow group@:--------------:-------:deny group@:rwxp----------:-------:allow everyone@:rwxp---A-W-Co-:-------:deny everyone@:------a-R-c--s:-------:allow -rw-rw---- 1 auser agroup 0 Mar 8 21:33 file owner@:--x-----------:-------:deny owner@:rw-p---A-W-Co-:-------:allow group@:--x-----------:-------:deny group@:rw-p----------:-------:allow everyone@:rwxp---A-W-Co-:-------:deny everyone@:------a-R-c--s:-------:allow Now reorder as you suggested and you will see your windows users start crying ...
Evaluating the problem again I finally found the root cause. Problem is in the fact the ZFS (even if "aclmode=passthrough" is set) is turning the file control bact to the POSIX (ZFS keeps the POSIX compatibility) on each (f)chmod() call. It represent adding the special ACEs to ACL derived from the POSIX mask on each (f)chmod() call. Fix was tested and source diff was attached to bug# 5653 . Solaris is still running samba-3.0.34 because of the GPLv3 legal issues.
Jiri, does that mean we can close this bug ?
I think this is not a bug. When you want to use ZFS and Samba zfsacl, you should do the following: 1. Set "aclinherit=passthrough" property on ZFS. # zfs set aclinherit=passthrough dpool/share 2. Adjust ACE order in ACL on the shared folder(s) to be compatible with Windows Explorer ACL editor. # chmod A=group:domain\ guests:rwxpdDaARWcCos:fd:deny,group:domgroup1:rwxpdDaARWcCos:fd:allow,owner@:rwxpdDaARWcCos:fd:allow /srv/share # ls -dV /srv/share drwx------+ 9 root root 10 Mar 26 06:21 /srv/share group:Domain Guests:rwxpdDaARWcCos:fd----:deny group:domgroup1:rwxpdDaARWcCos:fd----:allow owner@:rwxpdDaARWcCos:fd----:allow 3. Avoid chmod(2) by smbd. smb.conf: ## Solaris + ZFS ACL (NFSv4 ACL) with aclinherit=passthrough vfs objects = zfsacl nfs4:acedup = merge nfs4:chown = yes nfs4:mode = special ## ACL inheritance is done by ZFS inherit acls = no ## Avoid chmod(2) that breaks ACL inherit permissions = no force create mode = 00000 force security mode = 00000 force directory mode = 00000 force directory security mode = 00000 store dos attributes = yes ## ZFS ACL implements "write_acl" and "write_owner" permissions that ## is compatible with Windows (NT) ACL better than "dos filemode = yes" dos filemode = no
(In reply to Jura Sasek from comment #8) according to comment #8 this bug can be closed as the issue moved to bug 5653 *** This bug has been marked as a duplicate of bug 5653 ***