mapping SYNCHRONIZE permission in NTFS ACL for ZFS

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

mapping SYNCHRONIZE permission in NTFS ACL for ZFS

Paul B. Henson

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



--
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  [hidden email]
California State Polytechnic University  |  Pomona CA 91768
Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

Jiri Sasek - Solaris Prague
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) {
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

Paul B. Henson
On Tue, 11 Jan 2011, Jiri Sasek wrote:

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

For the record, the directory ACL is:

drwx--s--x+  3 henson   csupomona       6 Jan 11 13:02 .
            owner@:rwxpdDaARWcC--:------:allow

However, the problem comes and goes from just changing the file acl, it
doesn't seem the directory permissions are involved. In particular,
renaming via smbclient works fine, the failure on the windows client seems
to be an acl interpretation issue on the client side, not a permission
denied issue on the server.

Oh, and the test client is windows server 2008R2, if that matters.


--
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  [hidden email]
California State Polytechnic University  |  Pomona CA 91768
Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

David Disseldorp-2
In reply to this post by Paul B. Henson
Hi Paul,

On Tue, 11 Jan 2011 13:35:19 -0800 (PST)
"Paul B. Henson" <[hidden email]> wrote:
...
> 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?

The synchronize permission is a member of all Windows access limitation
groups (Modify, Read & Execute, List Folder Content, Read and Write.
I've not seen any reason to disable it, though that's not mean that
nothing does.

See http://technet.microsoft.com/en-us/library/cc732880.aspx

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

This appears to be based on the original NFSv4 specification (rfc3530).
FWIW the proposed NFSv4.1 spec (rfc5661) uses a completely different
interpretation of the synchronize permission much closer in line with
the Windows definition:

         Permission to use the file object as a synchronization
         primitive for interprocess communication.  This permission is
         not enforced or interpreted by the NFSv4.1 server on behalf of
         the client.
>
> 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.

This will not play nice with applications that explicitly disable the
synchronize permission.

Cheers, David
Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

Jeremy Allison
On Wed, Jan 12, 2011 at 12:39:42AM +0100, David Disseldorp wrote:

> Hi Paul,
>
> On Tue, 11 Jan 2011 13:35:19 -0800 (PST)
> "Paul B. Henson" <[hidden email]> wrote:
> ...
> > 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?
>
> The synchronize permission is a member of all Windows access limitation
> groups (Modify, Read & Execute, List Folder Content, Read and Write.
> I've not seen any reason to disable it, though that's not mean that
> nothing does.
>
> See http://technet.microsoft.com/en-us/library/cc732880.aspx
>
> > 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-/.
>
> This appears to be based on the original NFSv4 specification (rfc3530).
> FWIW the proposed NFSv4.1 spec (rfc5661) uses a completely different
> interpretation of the synchronize permission much closer in line with
> the Windows definition:
>
>          Permission to use the file object as a synchronization
>          primitive for interprocess communication.  This permission is
>          not enforced or interpreted by the NFSv4.1 server on behalf of
>          the client.
> >
> > 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.
>
> This will not play nice with applications that explicitly disable the
> synchronize permission.

Actually I've yet to see any application do so - at least for file
permissions.

I'd probably recommend just always setting the SYNCHRONIZE_ACCESS
bit when returning an ACL from ZFS/NFSv4 within Samba, and just
ignoring whether it's set on or not on read.

Jeremy.
Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

Paul B. Henson
In reply to this post by David Disseldorp-2
On Tue, 11 Jan 2011, David Disseldorp wrote:

> FWIW the proposed NFSv4.1 spec (rfc5661) uses a completely different
> interpretation of the synchronize permission much closer in line with
> the Windows definition:

Given NFSv4 ACL's were based on NTFS ACL's, it does seem to make more sense
to provide similar semantics, although given they still won't be enforced
on the server side it's mostly a documentation change.

> This will not play nice with applications that explicitly disable the
> synchronize permission.

Perhaps an option to the zfs_acl module then allowing my proposed behavior
to be enabled only when desired?


--
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  [hidden email]
California State Polytechnic University  |  Pomona CA 91768
Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

Paul B. Henson
In reply to this post by Jeremy Allison
On Tue, 11 Jan 2011, Jeremy Allison wrote:

> I'd probably recommend just always setting the SYNCHRONIZE_ACCESS bit
> when returning an ACL from ZFS/NFSv4 within Samba, and just ignoring
> whether it's set on or not on read.

If I understand your recommendation correctly, that's what my patch does,
as well as stripping the bit out when writing an ACL back to ZFS as not to
clutter the ACL with meaningless permissions on the local/NFS access side.


--
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  [hidden email]
California State Polytechnic University  |  Pomona CA 91768
Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

Jeremy Allison
On Tue, Jan 11, 2011 at 04:32:36PM -0800, Paul B. Henson wrote:
> On Tue, 11 Jan 2011, Jeremy Allison wrote:
>
> > I'd probably recommend just always setting the SYNCHRONIZE_ACCESS bit
> > when returning an ACL from ZFS/NFSv4 within Samba, and just ignoring
> > whether it's set on or not on read.
>
> If I understand your recommendation correctly, that's what my patch does,
> as well as stripping the bit out when writing an ACL back to ZFS as not to
> clutter the ACL with meaningless permissions on the local/NFS access side.

Hmmm. Yes. I was going to recommend leaving it alone on set,
but if it's really being defined as a server-side NO-OP then
there's really no need. Unless there are ported Windows apps
(wine maybe ?) that might want to see it when reading NFSv4
ACLs ? Ah, but then I guess they should just do the mapping
themselves...

I've also looked at the smbtorture4 RAW-ACLs test, and every
ACL we set there always uses SEC_STD_SYNCHRONIZE, so I think
we're ok here.

Can you do me a favour, and log a bug against 3.5.6 on bugzilla.samba.org
so I can add in the patch for 3.6.0 and a future 3.5.x release ?

Jeremy.
Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

Paul B. Henson
On Tue, 11 Jan 2011, Jeremy Allison wrote:

> Hmmm. Yes. I was going to recommend leaving it alone on set, but if it's
> really being defined as a server-side NO-OP then there's really no need.

A more general implementation would be to leave it set if it is set, but
not set it otherwise, but that would be more complicated. As far as I can
tell the function which is called to set the acl is passed the windows acl
and the file name with no knowledge of the existing acl. To maintain the
sync bit if set it would need to read in the existing acl and do a
comparision between the old and new. Possible, but doesn't really seem
worth the effort.

> Can you do me a favour, and log a bug against 3.5.6 on bugzilla.samba.org
> so I can add in the patch for 3.6.0 and a future 3.5.x release ?

Will do, thanks...


--
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  [hidden email]
California State Polytechnic University  |  Pomona CA 91768
Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

Jeremy Allison
On Tue, Jan 11, 2011 at 05:03:05PM -0800, Paul B. Henson wrote:

> On Tue, 11 Jan 2011, Jeremy Allison wrote:
>
> > Hmmm. Yes. I was going to recommend leaving it alone on set, but if it's
> > really being defined as a server-side NO-OP then there's really no need.
>
> A more general implementation would be to leave it set if it is set, but
> not set it otherwise, but that would be more complicated. As far as I can
> tell the function which is called to set the acl is passed the windows acl
> and the file name with no knowledge of the existing acl. To maintain the
> sync bit if set it would need to read in the existing acl and do a
> comparision between the old and new. Possible, but doesn't really seem
> worth the effort.

Yes, exactly what I decided also :-).

> > Can you do me a favour, and log a bug against 3.5.6 on bugzilla.samba.org
> > so I can add in the patch for 3.6.0 and a future 3.5.x release ?
>
> Will do, thanks...

Thanks - I'll add in the fix to active branches (and in the
generic NFSv4 ACL module) once you've logged the bug.

Cheers,

Jeremy.
Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

Paul B. Henson
On Tue, 11 Jan 2011, Jeremy Allison wrote:

> Thanks - I'll add in the fix to active branches (and in the generic NFSv4
> ACL module) once you've logged the bug.

Excellent, thanks much. It's bug #7909...


--
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  [hidden email]
California State Polytechnic University  |  Pomona CA 91768
Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

Jeremy Allison
In reply to this post by Paul B. Henson
On Tue, Jan 11, 2011 at 05:03:05PM -0800, Paul B. Henson wrote:

> On Tue, 11 Jan 2011, Jeremy Allison wrote:
>
> > Hmmm. Yes. I was going to recommend leaving it alone on set, but if it's
> > really being defined as a server-side NO-OP then there's really no need.
>
> A more general implementation would be to leave it set if it is set, but
> not set it otherwise, but that would be more complicated. As far as I can
> tell the function which is called to set the acl is passed the windows acl
> and the file name with no knowledge of the existing acl. To maintain the
> sync bit if set it would need to read in the existing acl and do a
> comparision between the old and new. Possible, but doesn't really seem
> worth the effort.
>
> > Can you do me a favour, and log a bug against 3.5.6 on bugzilla.samba.org
> > so I can add in the patch for 3.6.0 and a future 3.5.x release ?
>
> Will do, thanks...
Ok, here's the patch I'm planning for master. Can you test it
(I don't have access to a ZFS filesystem) for me please ?

The tricky part is that according to your results, all
UNIX filesystems that map onto NFSv4 ALCs should have
this change made (adding in the SYNCHRONIZE bit when returning
a Windows ACL). This means the logical place to do this is
not in modules/vfs_zfsacl.c, but in modules/nfs4_acls.c
which contains the master mapping code, so that's where
I've put it.

However, I'm assuming that the other filesystems that
support Samba mapping to NFSv4 ACLs (gpfs and aixacl2.c)
are ok with all incoming NFSv4 ACLs being rewritten on
write to contain the sync bit. They must already accept
it from a Windows ACL so I'm pretty sure this is ok.

I haven't added the code to strip the sync bit on write
to the gpfs and aixacl2 modules, as I don't think it's
really needed.

Do you want me to make the ZFS module code the same (i.e.
not strip the sync bit on write) ? It would make all modules
more consistent.

Jeremy.
Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

J. Bruce Fields
In reply to this post by Paul B. Henson
On Tue, Jan 11, 2011 at 01:35:19PM -0800, 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
...
> 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?

That sounds like a ZFS bug to me....  I've verified in the past that
their NFSv4 server always set SYCHRONIZE by default--I suppose that
could have been a hack in their NFSv4 server, or they could have changed
the behavior since then.  Either would be strange.

--b.
Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

Paul B. Henson
In reply to this post by Jeremy Allison
On Tue, 11 Jan 2011, Jeremy Allison wrote:

> Ok, here's the patch I'm planning for master. Can you test it (I don't
> have access to a ZFS filesystem) for me please ?

Looks good, all ACL's when viewed from the windows side appear to have sync
set, and ACL's written from windows don't add sync to the underlying ZFS
ACL.

> This means the logical place to do this is not in modules/vfs_zfsacl.c,
> but in modules/nfs4_acls.c which contains the master mapping code, so
> that's where I've put it.

I considered that, but didn't necessarily want to muck with the generic
nfs4 code for my specific need. I agree that's the better place to do it if
windows will always need the sync bit set in general.

> However, I'm assuming that the other filesystems that support Samba
> mapping to NFSv4 ACLs (gpfs and aixacl2.c) are ok with all incoming NFSv4
> ACLs being rewritten on write to contain the sync bit. They must already
> accept it from a Windows ACL so I'm pretty sure this is ok.

I'm not sure what you mean; the change to the generic nfs4 code only
results in the sync bit being added when converting an ACL to send it to
windows, there's no change in the generic nfs4 code for taking a windows
ACL and writing it out on the unix side. For the other filesystems using
the nfs4 code that will continue to work as it always did.

> I haven't added the code to strip the sync bit on write to the gpfs and
> aixacl2 modules, as I don't think it's really needed.
>
> Do you want me to make the ZFS module code the same (i.e. not strip the
> sync bit on write) ? It would make all modules more consistent.

No; I definitely want the sync bit stripped before writing out the ZFS ACL.
Given it's a noop on the zfs side, there's no functional difference, but
there's a user interface difference. The underlying ACL is modified on the
unix side both by interactive users at shell prompts and also by a web gui
our webdev group put together that's layered on top of the zfs ACL. Having
the sync bit start popping up everywhere a windows box happens to have
touched the acl will be confusing, and possibly even break the webapp if
they didn't account for it. And just on general principal I don't want my
ACL's cluttered up with meaningless bits.

While the stripping not be strictly needed, given that the sync bit is
meaningless on the unix side, to make all the modules consistent I think it
would be better to strip everywhere. Perhaps it could be a new option for
the nfs4 module, like "stripsync". Defaulting to false for backwards
compatibility (or to true for forward adaptability ;) ), when set to true
it would strip the sync bit from the acl before writing it out.

Per the AIX docs:

http://publib.boulder.ibm.com/infocenter/aix/v6r1/topic/com.ibm.aix.security/doc/security/acl_nfs4.htm

-----
Note: Concerning the SYNCHRONIZE Ace_Mask value key, s, AIX does not take
any action concerning this value key. AIX stores and preserves the s value
key but this value key does not have any meaning to AIX.
-----

It seems the only reason the sync bit exists in nfs4 is because it was
copied from the ntfs acl. I'm not aware of anything on the unix side that
cares about it. Windows seems to (virtually) always want it on. It seems
cleanest to just always set it for the acl returned to windows, but strip
it from the acl coming from windows. It's a trivial amount of extra work to
create the new option for the nfs4 module to allow optional stripping, so
maybe that's the best course of action?

Or I'd be perfectly happy with the patch as is, it addresses my needs :).

Thanks...


--
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  [hidden email]
California State Polytechnic University  |  Pomona CA 91768
Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

Paul B. Henson
In reply to this post by J. Bruce Fields
On Wed, 12 Jan 2011, J. Bruce Fields wrote:

> That sounds like a ZFS bug to me....  I've verified in the past that
> their NFSv4 server always set SYCHRONIZE by default--I suppose that could
> have been a hack in their NFSv4 server, or they could have changed the
> behavior since then.  Either would be strange.

Hmm, I don't know what it used to do, but we've used the NFSv4 server on
top of zfs since Solaris 10 update 6, and I've never seen the sync bit set
unless there was a windows box involved via samba... I'm not sure what the
in-kernel CIFS server does under OpenSolaris/Solaris Express.


--
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  [hidden email]
California State Polytechnic University  |  Pomona CA 91768
Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

J. Bruce Fields
On Wed, Jan 12, 2011 at 08:17:53PM -0800, Paul B. Henson wrote:

> On Wed, 12 Jan 2011, J. Bruce Fields wrote:
>
> > That sounds like a ZFS bug to me....  I've verified in the past that
> > their NFSv4 server always set SYCHRONIZE by default--I suppose that could
> > have been a hack in their NFSv4 server, or they could have changed the
> > behavior since then.  Either would be strange.
>
> Hmm, I don't know what it used to do, but we've used the NFSv4 server on
> top of zfs since Solaris 10 update 6, and I've never seen the sync bit set
> unless there was a windows box involved via samba... I'm not sure what the
> in-kernel CIFS server does under OpenSolaris/Solaris Express.

Huh.  I still have my test results.  Looking back at them, I see that it
always returned an ACL ending in an allow EVERYONE@ entry including
the synchronize bit.

That was several years ago, though, and come to think of it that *may*
have been some translation layer on top of UFS at the time, instead of
ZFS....

Still, I doubt leaving synchronize unset is what they intended, so it
might be worth reporting as a bug if you think it would get any
attention.

--b.
Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

Gordon Ross-10
[...]
> Still, I doubt leaving synchronize unset is what they intended, so it
> might be worth reporting as a bug if you think it would get any
> attention.

I've known about this bug for a while.  I thought we had an "issue"
for this already, but I couldn't find it, so I filed a new one:
http://www.illumos.org/issues/627

Yes, the SYNC bit is missing sometimes when it should be there.
I advise setting the bit (where appropriate) before storing an ACL.

Gordon
Reply | Threaded
Open this post in threaded view
|

Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS

Paul B. Henson
On Thu, 13 Jan 2011, Gordon Ross wrote:

> I've known about this bug for a while.  I thought we had an "issue" for
> this already, but I couldn't find it, so I filed a new one:
> http://www.illumos.org/issues/627
>
> Yes, the SYNC bit is missing sometimes when it should be there. I advise
> setting the bit (where appropriate) before storing an ACL.

Given nothing on the unix side pays any attention to it (that I know of, is
there something you're aware of that does?) it seems annoying to suddenly
have it popping up all over.

What does the in-kernel solaris CIFS server do? I've never used it, but
don't recall seeing the sync bit set in the ACL's posted in threads from
people that do.

My preference is to feed it to windows because it breaks in funny ways if
it's not set, but to leave it out of the unix picture so it doesn't clutter
the ACL.


--
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  [hidden email]
California State Polytechnic University  |  Pomona CA 91768