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
