mapping SYNCHRONIZE permission in NTFS ACL for ZFS

[Paul B. Henson]

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  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768