Re: OpenZFS on NetBSD

[zakinko <zakinko%snowrabbit.org@localhost>]

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 <od2uvb%0w.se@localhost>:
>
> 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