Re: OpenZFS on NetBSD

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

I tried aclmode=passthrough as I said I would, and I did not find
anything to fix in OpenZFS.
I ran it on NetBSD 11.0 with the OpenZFS port and on FreeBSD 15.0, and
both behaved the same. The share allows named groups and denies a
group that holds every user, all inherited with fd, so the deny
catches anyone the allows did not:

setfacl -m 'g:admins:full_set:fd:allow,g:teachers:rwxpDdaARWcs:fd:allow,g:students:rxaRcs:fd:allow,g:everybody:full_set:fd:deny'
/tank/share

With aclmode=passthrough and aclinherit=passthrough the named entries
survived the owner's chmod 600, 666, 777 and 000, and they survived
vim, sed -i, cp, cp -p, install, tar -xp, rsync -a and mv. After chmod
777 a user in no allow entry still could not reach the file or the
directory, and a student still could not write. A teacher who does not
own the file could save it with all of those tools. On NetBSD cp -p
wrote the data and then reported an error from chmod and chflags.
A teacher's chmod fails without write_acl, as POSIX leaves chmod to
the owner, and with write_acl they can rewrite the ACL too, because
the NFSv4.1 specification, RFC 8881, makes that one right cover both.
The owner can rewrite the ACL even where it denies write_acl. RFC 8881
section 6.3.1.1 allows a server to grant that but does not require it.
Saving by rename makes the person saving the owner. A user outside the
all-users group gets in through everyone@ after chmod 666, and a
directory above that gives them nothing stops that; I checked it.
The aclmode=decoupled you suggested would close that last one, since
chmod would stop rewriting those entries. It looks to me like the mode
and ACL would then differ in the way RFC 8881 sections 6.4.1.1 and
6.4.2 rule out for owner@, group@ and everyone@, so I have not gone
further with it. I understand the 2018 thread treated this as a choice
an administrator makes knowingly.
For the owner's right, draft-ietf-nfsv4-acls-update-06 has
OWNER_RIGHTS@, like S-1-3-4 on Windows. It is still a draft. It
cancels the owner's write_acl, and since that right also covers the
mode, the owner's chmod would go with it, though the draft does not
mention chmod. Other parts of it may change what passthrough does. I
would like to leave this with the people working on NFS.

-- 
zakinko

2026年11月4日(水) 20:53 zakinko <zakinko%snowrabbit.org@localhost>:
>
> Thank you for both mails, and for the pointer to the 2018 thread,
> which I have now read through.
>
> 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, 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.
>
> 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.
>
> --
> zakinko
>
> 2026年11月4日(水) 19:52 <od2uvb%0w.se@localhost>:
> >
> > On Mon, Nov 02, 2026 at 01:49:23PM +0100, od2uvb%0w.se@localhost wrote:
> > > This issue has been discussed on the zfs-devel mailing list at least once
> > > (in July 2018)
> >
> > https://zfsonlinux.topicbox.com/groups/zfs-devel/T82e4ca6ba5be23dd/zfs-devel-acls-usability-was-re-native-zfs-nfs4-acl-support-issue-4966
> >
> > Please check the system administrator view there. Otherwise it looks
> > like the worlds of zfs-developers and system administrators had been
> > isolated from each other.
> >
> > The zfs acl functionality has remained woefully inadequate for decades, on
> > all platforms. NetBSD has a chance to do it right (and fully compatible,
> > if the other aclmodes are made available). The "aclmode=decoupled"
> > is presumably also the easiest mode to implement and debug first.
> >
> > The interaction between acls and "owner"/"group"-based rights evaluation
> > is in the platform-specific ZFS code. This presents an opportunity to
> > avoid importing the enforced conflation from Linux and FreeBSD.
> >
> > /od2uvb