Re: OpenZFS on NetBSD

[od2uvb%0w.se@localhost]

Hello zakinko,

On Thu, Nov 05, 2026 at 08:29:38PM +0900, zakinko wrote:
> 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.

Why does ZFS have to follow NFS in this respect? This should not be
necessary at least in the installations which do not export ZFS via
NFS. Also, what NFS exposes and applies does not have to be exactly what
the underlying file system offers.

The owner exception is a feature very deeply connected to the Unix
original acl model aka modebits. It is contradicting the very role of
the _Access_Control_ list, thus is counterproductive and confusing.
Above all, it is _not_ necessary.
An exception for root is fully sufficient.

Consider also that the users can easily isolate themselves from their data
in other ways. It is e.g. easy to unlink() a newly edited large file.
There is not even any "superuser exception" in Unix for reverting the result.

> So what you are running into comes from those
> rules rather than from ZFS itself.

ZFS is not a part of NFS, nor vice versa, why are you assuming
that they must behave identically?

Of course, NFS suffers from the same design problem that we discuss. Worse,
the draft-ietf-nfsv4-acls-update-06 which you mentioned, seems to make the
rules even more complicated, for the sake of a specific implementation
of yet non-standard ACLs (Linux ones). That's very sad.

> 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.

No, they could not rewrite. "Decoupled" must _not_ have any exceptions
for the owner. ACLs do not have to bear the load of bad Unix heritage.

ACLs are very easy to explain when they do not depend on properties like
"who has created the file" and "to which group that process belonged"
and "which umask that process had."

> 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.

Why would NFS clients have to learn? Why not the users? They in any
case must be somehow made aware of the server policies.

The proposed decoupled mode does not break any usual Unix semantics,
besides for programs who try to use access bits for security-related
conclusions. This practice is not only racy but plainly wrong as soon
as there is an ACL richer than modebits.
The usual chmod command can always give a relief to such an application,
in decoupled mode the ACLs do not influence modebits operations.

> The nfsv4 working group is revising these rules now in
> draft-ietf-nfsv4-acls-update. ...
> goes the other way from what you want
> ...
> I think your examples would be worth bringing there.

It is apparent that the working group has an agenda unrelated to reducing
confusion. I think the only argument, if any, that possibly could influence
such a group would be a working implementation, delivering its promise
in practice. The users will love it.

Thanks
/od2uvb