Thank you for the details from your systems. Daily ACL fixes sound like a real burden.
I take your point about XBD 4.7, and as you say, the RFC itself only governs NFSv4. What ZFS stores, though, is an NFSv4 ACL. chmod rewrites owner@, group@ and everyone@ because RFC 8881 section 6.4.1.1 says the mode and the ACL have to agree, and the owner can rewrite the ACL because section 6.3.1.1 lets a server grant WRITE_ACL on its own, so that an ACL can always be repaired. So what you are running into comes from those rules rather than from ZFS itself. That is why I would rather not do this as an aclmode in ZFS, and a decoupled aclmode would not cover everything you list anyway, as the owner could still rewrite the ACL. I can see the value of a knob for finding out what people actually prefer, but it would help only one file system, and NFSv4 clients would have no way to learn that this server handles a mode change differently. The nfsv4 working group is revising these rules now in draft-ietf-nfsv4-acls-update. Of the things you list, the draft so far addresses only the owner's rights, through OWNER_RIGHTS@. Its current text on chmod goes the other way from what you want: ACEs for named users would be kept only if they no longer affect access. It also says this still needs discussion. Its ACL_Choice attribute lets a server tell clients how it handles a mode change, and new behaviours can be added there, so a server that leaves the ACL alone might be able to say so. I think your examples would be worth bringing there. -- zakinko 2026年11月5日(木) 18:04 <[email protected]>: > > Thanks a lot for looking at this seriously. > > On Wed, Nov 04, 2026 at 08:53:16PM +0900, zakinko wrote: > > 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 > > This sounds great! > > > 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. > > Thank you for the pointers. > > Reading The Open Group Base Specifications Issue 8 IEEE Std 1003.1-2024 > XKB 4.7: > "An alternate file access control mechanism shall: > * Specify file permission bits for the file owner class, file group > class, and file other class of that file, corresponding to the > access permissions." > > As far as I can see, strictly interpreted this would be a bug > in the standard. It is not possible to express a large class of access > permissions (e.g. involving more than one group) in modebits values. > > On the other hand, if "corresponding" is to be interpreted as > "approximating", then it looks ok, even though in the decoupled case > the approximation would be really loose. No metrics of "approximation > proximity" is specified in the standard though. > > The more troubling parts are " > * Be enabled only by explicit user action, on a per-file basis by the > file owner or a user with appropriate privileges. > * Be disabled for a file after the file permission bits are changed > for that file with chmod()." > > This does preclude having file trees managed by ACLs, because the users > would escape the ACLs at creation of new files and at every chmod(). > > Given that ACLs in every implementation known to me have a provision > to automatically be inherited by newly created files, I doubt that this > part of the standard is being taken seriously. > > Otherwise, the use of ACLs must be restricted to being only an > "additional", not "alternative" mechanism and only be able to further > restrict access with respect to modebits. > "An additional access control mechanism shall only further restrict the > access permissions defined by the file permission bits." > This would make it impossible e.g. to grant rights to more than one > group without granting them to everyone. > > IOW I do not see a reason to follow this part of the standard, which is > already ignored in practice. Am I looking at the current version? > > RFC 8881 is still only a "proposed standard" which means it can be > changed. It governs also only NFSv4, which does not prevent ZFS from > having a better ACL functionality. Nor does it preclude having multiple > different aclmodes in ZFS. > > > 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. > > I do not think owner@ and group@ should be involved in any way. > They confuse the users a lot and I would wish them at best not show up > at all or at least be filled with something apparently irrelevant like > all-zeros, of course stating this in the documentation for the aclmode. > Everyone@ can be applicable to filesets with public data, but it shall > not have any relation to modebits. > > Yes, empty owner@/group@ ACEs might lead to surprises when moving ZFS > pools to other OSes not (yet?) supporting decoupled, but all-zeros would > be safe and setting the ACEs to some other value would only need a single > run over the corresponding file tree, once, compared to daily ACL fixes > currently needed. > > Regarding your next message: > On Thu, Nov 05, 2026 at 01:00:00PM +0900, zakinko wrote: > > I tried aclmode=passthrough as I said I would, and I did not find > > anything to fix in OpenZFS. > > Implementation of passthrough is probably working as intended. > It is nevertheless unfortunately, from the perspective of myself and of > my systems management colleagues, after over a decade with ZFS and NFSv4, > not the desired functionality. > > You mention deficiencies like > > On NetBSD cp -p wrote the data and then reported an error from chmod > > and chflags. > > A failing chmod() unfortunately breaks all programs who check its > return status. This also indirectly breaks programs who (regrettably) > analyze modebits. A prominent example is ssh but there are others too. > > It is very hard to explain to the users why they encounter errors, > because the underlying logic is neither intuitive nor for the users > practically useful. > > > A user outside the > > all-users group gets in through everyone@ after chmod 666. > > > The owner can rewrite the ACL even where it denies write_acl. > > These directly break the function of the ACL and make it impossible to > have consistent permissions in shared areas. > > The passthrough mode does not look adequate, nor seems to be compliant > with XBD 4.7. > > A cleanly decoupled aclmode would be highly appreciated and would also > allow to actually observe whether it will be preferred/popular compared > to the other aclmodes. > > Last but not least, a consistent, easily analyzable privilege setup is > very important for handling security. > > Thanks a lot for your work! > > /od2uvb
