Re: OpenZFS on NetBSD

[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