mapping SYNCHRONIZE permission in NTFS ACL for ZFS

[Jiri Sasek]

Hi Paul,

To know more about your privileges on renaming the file you should 
rather to display the directory ACL.

i.e.:

  $ ls -dV .
drwxrwxrwx  15 root     root          39 Jan 10 19:28 .
                  owner@:--------------:-------:deny
                  owner@:rwxp---A-W-Co-:-------:allow
                  group@:--------------:-------:deny
                  group@:rwxp----------:-------:allow
               everyone@:-------A-W-Co-:-------:deny
               everyone@:rwxp--a-R-c--s:-------:allow

( .../henson/tmp/  ... in your case)

Regards,

Jura

On 01/11/11 10:35 PM, Paul B. Henson wrote:
> I'm working with Solaris' bundled version of samba 3.5.5, and am seeing
> some weirdness with ACL mapping between ZFS and windows. By default (in my
> configuration), a new file in a directory inherits an initial (zfs) acl
> like:
>
> -rw-------+  1 henson   csupomona       0 Jan 11 12:32 test.txt
>              owner@:rw-pdDaARWcC--:------:allow
>
> Or more verbosely:
>
> -rw-------+  1 henson   csupomona       0 Jan 11 12:32 test.txt
>       0:owner@:read_data/write_data/append_data/read_xattr/write_xattr
>           /delete_child/read_attributes/write_attributes/delete/read_acl
>           /write_acl:allow
>
> With this acl, windows refuses to rename the file. A dialog box pops up
> saying:
>
> 	"File Access Denied"
> 	"You need permission to perform this action"
> 	"You require permission from \henson to make changes to this file"
>
> This is completely from the client side, connecting with smbclient allows
> renaming fine.
>
>  From the windows side, the ACL looks like:
>
> \\ike.unx.csupomona.edu\henson\tmp\test.txt WIN\henson:(special access:)
>                                                       DELETE
>                                                       READ_CONTROL
>                                                       WRITE_DAC
>                                                       FILE_READ_DATA
>                                                       FILE_WRITE_DATA
>                                                       FILE_APPEND_DATA
>                                                       FILE_READ_EA
>                                                       FILE_WRITE_EA
>                                                       FILE_DELETE_CHILD
>                                                       FILE_READ_ATTRIBUTES
>                                                       FILE_WRITE_ATTRIBUTES
>
>
> I traced this down to the syncronize permission not being set. If I add the
> syncronize permission on the zfs side, the windows acl turns into:
>
> \\ike.unx.csupomona.edu\henson\tmp\test.txt WIN\henson:(special access:)
>                                                        DELETE
>                                                        READ_CONTROL
>                                                        WRITE_DAC
>                                                        SYNCHRONIZE
>                                                        FILE_GENERIC_READ
>                                                        FILE_GENERIC_WRITE
>                                                        FILE_READ_DATA
>                                                        FILE_WRITE_DATA
>                                                        FILE_APPEND_DATA
>                                                        FILE_READ_EA
>                                                        FILE_WRITE_EA
>                                                        FILE_DELETE_CHILD
>                                                        FILE_READ_ATTRIBUTES
>                                                        FILE_WRITE_ATTRIBUTES
>
> In addition to "SYNCHRONIZE", "FILE_GENERIC_READ" and "FILE_GENERIC_WRITE"
> seem to have materialized. With this ACL, renaming works fine.
>
> I also noticed that whenever an acl is set from the windows side, it also
> includes the SYNCHRONIZE permission for all entries. That permission isn't
> listed in the GUI, although the command line icacs program allows you to
> control it. It seems SYNCHRONIZE more or less should always be on?
>
>  From MSDN:
>
> "The Synchronize permission allows or denies different threads to wait on
> the handle for the file or folder and synchronize with another thread that
> may signal it. This permission applies only to multiple-threaded,
> multiple-process programs. "
>
> On the other hand, the syncronize permission under zfs is:
>
>       synchronize (s)         Permission to access file locally at
>                               server  with  synchronize  reads and
>                               writes.
>
>                               Currently, this  permission  is  not
>                               supported.
>
> Not only is this completely different, it's not even implemented 8-/.
>
> I don't really want the zfs syncronize permission set on all my zfs stuff.
> It seems the best thing to do is to simply always flip that bit on when the
> acl is sent to windows, and always flip it off when a windows acl is
> written to a zfs object.
>
> I wrote a simple patch to do so. Any feedback on whether this is a good
> solution, or recommendations on a better one, would be much appreciated.
>
>
> *** vfs_zfsacl.c.orig   Tue Jan 11 13:05:08 2011
> --- vfs_zfsacl.c        Tue Jan 11 13:00:59 2011
> ***************
> *** 77,82 ****
> --- 77,83 ----
>                  aceprop.aceType  = (uint32) acebuf[i].a_type;
>                  aceprop.aceFlags = (uint32) acebuf[i].a_flags;
>                  aceprop.aceMask  = (uint32) acebuf[i].a_access_mask;
> +               aceprop.aceMask  |= SMB_ACE4_SYNCHRONIZE;
>                  aceprop.who.id   = (uint32) acebuf[i].a_who;
>
>                  if(aceprop.aceFlags&  ACE_OWNER) {
> ***************
> *** 123,128 ****
> --- 124,130 ----
>                  acebuf[i].a_type        = aceprop->aceType;
>                  acebuf[i].a_flags       = aceprop->aceFlags;
>                  acebuf[i].a_access_mask = aceprop->aceMask;
> +               acebuf[i].a_access_mask&= ~SMB_ACE4_SYNCHRONIZE;
>                  acebuf[i].a_who         = aceprop->who.id;
>                  if(aceprop->flags&  SMB_ACE4_ID_SPECIAL) {
>                          switch(aceprop->who.special_id) {
>
>
>