I tried aclmode=passthrough as I said I would, and I did not find anything to fix in OpenZFS. I ran it on NetBSD 11.0 with the OpenZFS port and on FreeBSD 15.0, and both behaved the same. The share allows named groups and denies a group that holds every user, all inherited with fd, so the deny catches anyone the allows did not:
setfacl -m 'g:admins:full_set:fd:allow,g:teachers:rwxpDdaARWcs:fd:allow,g:students:rxaRcs:fd:allow,g:everybody:full_set:fd:deny' /tank/share With aclmode=passthrough and aclinherit=passthrough the named entries survived the owner's chmod 600, 666, 777 and 000, and they survived vim, sed -i, cp, cp -p, install, tar -xp, rsync -a and mv. After chmod 777 a user in no allow entry still could not reach the file or the directory, and a student still could not write. A teacher who does not own the file could save it with all of those tools. On NetBSD cp -p wrote the data and then reported an error from chmod and chflags. A teacher's chmod fails without write_acl, as POSIX leaves chmod to the owner, and with write_acl they can rewrite the ACL too, because the NFSv4.1 specification, RFC 8881, makes that one right cover both. The owner can rewrite the ACL even where it denies write_acl. RFC 8881 section 6.3.1.1 allows a server to grant that but does not require it. Saving by rename makes the person saving the owner. A user outside the all-users group gets in through everyone@ after chmod 666, and a directory above that gives them nothing stops that; I checked it. The aclmode=decoupled you suggested would close that last one, since chmod would stop rewriting those entries. It looks to me like the mode and ACL would then differ in the way RFC 8881 sections 6.4.1.1 and 6.4.2 rule out for owner@, group@ and everyone@, so I have not gone further with it. I understand the 2018 thread treated this as a choice an administrator makes knowingly. For the owner's right, draft-ietf-nfsv4-acls-update-06 has OWNER_RIGHTS@, like S-1-3-4 on Windows. It is still a draft. It cancels the owner's write_acl, and since that right also covers the mode, the owner's chmod would go with it, though the draft does not mention chmod. Other parts of it may change what passthrough does. I would like to leave this with the people working on NFS. -- zakinko 2026年11月4日(水) 20:53 zakinko <[email protected]>: > > Thank you for both mails, and for the pointer to the 2018 thread, > which I have now read through. > > I had first tried an aclmode=ignore, and that turned out to be the > ignored no-op the thread warns about. I then rewrote it the way the > thread describes as aclmode=decoupled, but I have not tested that yet, > and I have come to wonder whether it is a good direction. With it the > mode no longer matches the ACL, and POSIX (XBD 4.7) and RFC 8881 > section 6.4 both ask that the two be kept in step, so it could be a > hard one to get accepted. > > Before going further I would like to see how far the existing > aclmode=passthrough can go. It keeps ACEs for named users and groups > across chmod and only rewrites owner@, group@ and everyone@, so a > share whose rights are all in named groups may behave well already, > although everyone@ needs some care. I will try this and write again > with what I find. > > -- > zakinko > > 2026年11月4日(水) 19:52 <[email protected]>: > > > > On Mon, Nov 02, 2026 at 01:49:23PM +0100, [email protected] wrote: > > > This issue has been discussed on the zfs-devel mailing list at least once > > > (in July 2018) > > > > https://zfsonlinux.topicbox.com/groups/zfs-devel/T82e4ca6ba5be23dd/zfs-devel-acls-usability-was-re-native-zfs-nfs4-acl-support-issue-4966 > > > > Please check the system administrator view there. Otherwise it looks > > like the worlds of zfs-developers and system administrators had been > > isolated from each other. > > > > The zfs acl functionality has remained woefully inadequate for decades, on > > all platforms. NetBSD has a chance to do it right (and fully compatible, > > if the other aclmodes are made available). The "aclmode=decoupled" > > is presumably also the easiest mode to implement and debug first. > > > > The interaction between acls and "owner"/"group"-based rights evaluation > > is in the platform-specific ZFS code. This presents an opportunity to > > avoid importing the enforced conflation from Linux and FreeBSD. > > > > /od2uvb
