OpenZFS on NetBSD

[od2uvb%0w.se@localhost]

Hello,

Showta Ishizaki's message made me aware that someone is working on Subj.

This might be a suitable occasion to mention a logically very simple
and at the same time very useful, but faulty/missing feature in ZFS.

For years I have been confronted with broken semantics of access control
lists on ZFS. The problem is that there is no aclmode which would
decouple them from the Unix mode bits.

The problem becomes apparent as soon as you for example try to use ZFS for
"group areas" where multiple persons shall have read and write access
rights. As soon as some participant does a chmod (even inadvertently,
when some software does this without asking), the ACLs break. This is
impossible to prevent.

The only workaround is running scheduled fix-up scripts, combing the file
trees and restoring the ACLs.

This issue has been discussed on the zfs-devel mailing list at least once
(in July 2018) but without any outcome.

Paul B. Henson seemed to have suggested something more or less similar even
5 years earlier, in 2013:
> https://illumos.org/issues/3571

Note the line "Currently I have to intervene frequently to reset the ACL."

This is what is being done on ZFS installations I know, except the ones
who for this very reason had to resign from using the ACLs.

It is a pity that for over a decade nothing has changed to make ACLs
consistently working and generally usable.

I have looked at the OpenZFS code, both for Linux and FreeBSD and
unfortunately it is built around the kernel's interpretation of mode
bits. In other words, a lightweight patch to add a "decoupled acl" mode
does not look feasible, the logic of privilege evaluation has to be
refactored to make it possible.

It would very useful if NetBSD could apply such refactoring and offer
practically useful, not crippled ACLs.

Could this (an aclmode where privilege evaluation fully ignores mode
bits) be considered for the port apparently being in the works?

Cheers,
od2uvb