Re: nfs4-acl-tools 0.3.5

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Aug 23, 2018 at 12:41:49PM -0700, Paul B. Henson wrote:
> On 8/23/2018 7:38 AM, J. Bruce Fields wrote:
> 
> >>Does something specifically need to be done individually for each
> >>file system, or if it supports the standard extended attribute does
> >>any file system (including an out of tree file system)
> >>automatically function?
> >
> >Nothing special's required, it should be automatic.
> 
> So if, hypothetically, the NFSv4 server was enhanced to look for and
> understand the standard linux system.nfs4_acl extended attribute,
> any file system, whether in kernel or out of tree, would support
> exposing NFSv4 ACLs via NFS? Even though there's nothing ZFS
> specific about it, that general functionality would not be
> acceptable for inclusion in the mainstream kernel?

Right, it's against kernel policy, and even if it weren't, I don't want
to be in the position of maintaining code, even simple code, that's
really only needed for third-party modules without any path to upstream.

> That seems a bit of a chicken and egg problem, do you add a feature
> for a subsystem to use so said subsystem could be updated to use it,
> or you update a subsystem to use a feature that doesn't exist yet
> :)?

Honestly the system.nfs4_acl extended attribute interface, which just
exposes the raw xdr of the ACL to userspace, is kind of a kludge.  It
could be made to work for other filesystems but I was hoping that other
filesystems would adopt something designed for them from scratch (like
richacls).

That said, there *is* already an in-kernel filesystem that supports
system.nfs4_acl: knfsd does actually allow limited re-export of NFS.  So
knfsd code that used system.nfs4_acl when available might actually have
some use, I don't really know.  I'm a little skeptical of the idea, to
be honest.

--b.