Bug 7909 - map SYNCHRONIZE acl permission statically in zfs_acl vfs module
Summary: map SYNCHRONIZE acl permission statically in zfs_acl vfs module
Alias: None
Product: Samba 3.5
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: 3.5.6
Hardware: Other Solaris
: P3 normal
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
Depends on:
Reported: 2011-01-11 19:16 UTC by Paul B. Henson
Modified: 2017-11-01 08:33 UTC (History)
3 users (show)

See Also:

Patch for 4.6 and 4.7 cherry-picked from master (2.49 KB, patch)
2017-09-27 12:58 UTC, Ralph Böhme
jra: review+

Note You need to log in before you can comment on or make changes to this bug.
Description Paul B. Henson 2011-01-11 19:16:04 UTC
As discussed on the samba-technical mailing list:


the SYNCHRONIZE acl permission should always be set in a zfs-sourced acl returned via CIFS, and dropped from the access_mask when writing a CIFS-sourced acl to zfs.
Comment 1 Jeremy Allison 2011-01-13 12:28:35 UTC
Fix pushed to master and 3.6 as git commit 75132a58c77257da5c90b92f08941dadb6aab00c. Let me know if you need this back-ported to 3.6.7.

Comment 2 Ralph Böhme 2017-09-06 10:58:51 UTC
This patch imposes special and questionable behaviour that was deemed desired for ZFS to all other VFS modules that use the common NFS4 ACL framework.

The generic framework should allow getting and setting SEC_STD_SYNCHRONIZE. If ZFS needs special behaviour, this must be put into vfs_zfsacl.

Having divergent behaviour wrt to SEC_STD_SYNCHRONIZE in all modules that use the NFS4 ACL framework also means that torture tests like "raw.acls.generic" fail and can't be used to test the modules which severly limits test coverage.

Will post a fix...
Comment 3 Paul B. Henson 2017-09-06 20:07:25 UTC
Well; more accurately I would say that a generic issue was discovered while using ZFS where Windows basically displays an undesirable lack of functionality when presented with an ACL without the SYNCHRONIZE bit set, and it was decided to fix this overall rather than just in a specific scenario.

But I originally proposed just fixing ZFS, Jeremy decided to move it up to the higher NFS layer, so as long as you don't break or change the patch functionality in the ZFS case I don't have any skin in this ;).

Back in 2011 there was really no NFS related functionality for the SYNCHRONIZE bit; has that changed? At the time it seemed to only exist due to being inherited from NTFS and was a bit in search of a purpose.

If there's going to be a change, I still like the idea of an option allowing a user to choose per instantiation whether to map the bit to and from the underlying fs or just ignore the fs and always return it on and ignore modification attempts...
Comment 4 Ralph Böhme 2017-09-27 12:58:10 UTC
Created attachment 13637 [details]
Patch for 4.6 and 4.7 cherry-picked from master
Comment 5 Jeremy Allison 2017-09-30 00:48:48 UTC
Re-assigning to Karolin for inclusion in 4.7.next, 4.6.next.
Comment 6 Karolin Seeger 2017-10-24 07:53:56 UTC
(In reply to Jeremy Allison from comment #5)
Pushed to autobuild-v4-{7,6}-test.
Comment 7 Karolin Seeger 2017-11-01 08:33:10 UTC
(In reply to Karolin Seeger from comment #6)
Pushed to both branches.
Closing out bug report.