Bug 5652 - default ZFS/NFSv4 ACL is not correctly ordered on Win
Summary: default ZFS/NFSv4 ACL is not correctly ordered on Win
Status: RESOLVED DUPLICATE of bug 5653
Alias: None
Product: Samba 3.2
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: unspecified
Hardware: All Solaris
: P3 normal
Target Milestone: ---
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
Depends on:
Blocks: 5653
  Show dependency treegraph
Reported: 2008-07-30 17:16 UTC by Jura Sasek
Modified: 2021-03-10 18:35 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Jura Sasek 2008-07-30 17:16:10 UTC
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/

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.
Comment 1 Jura Sasek 2008-07-30 17:37:43 UTC
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

Comment 2 Nils Goroll 2008-07-31 03:44:20 UTC
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 

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.
Comment 3 Jens Elkner 2009-02-17 22:18:04 UTC
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.
Comment 4 Jura Sasek 2009-03-06 18:57:14 UTC
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!!!
Comment 5 Nils Goroll 2009-03-08 08:18:08 UTC

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.
Comment 6 Nils Goroll 2009-03-08 08:20:43 UTC
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.
Comment 7 Jens Elkner 2009-03-08 15:57:31 UTC

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 .
-rw-rw----   1 auser   agroup            0 Mar  8 21:33 file

Now reorder as you suggested and you will see your windows users start crying ...

Comment 8 Jura Sasek 2009-03-26 16:40:58 UTC
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.
Comment 9 Guenther Deschner 2009-08-06 08:44:08 UTC
Jiri, does that mean we can close this bug ?
Comment 10 SATOH Fumiyasu 2012-03-25 21:26:04 UTC
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

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
Comment 11 Björn Jacke 2021-03-10 18:35:38 UTC
(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 ***