Re: [RFC PATCH v2 00/11] NFS/NFSD: nfs4_acl passthru for NFSv4 reexport

[Mike Snitzer <snitzer@kernel.org>]

On Tue, Feb 24, 2026 at 04:58:10PM -0500, Chuck Lever wrote:
> 
> On Tue, Feb 24, 2026, at 2:24 PM, Mike Snitzer wrote:
> > Hi,
> >
> > This patchset aims to enable NFS v4.1 ACLs to be fully supported from
> > an NFS v4.1 client to an NFSD v4.1 export that reexports NFS v4.2
> > filesystem which has full support for NFS v4.1 ACLs (DACL and SACL).
> >
> > The first 6 patches focus on nfs4_acl passthru enablement (primarily
> > for NFSD), patch 7 adds 4.1 nfs4_acl passthru support (DACL and SACL),
> > patch 8 optimizes particular nfs4_acl passthru implementation in NFSD
> > to skip memcpy if nfs4_acl passthru isn't needed, patches 9-11 offer
> > the corresponding required NFSv4 client changes.
> >
> > This work is based on the nfsd-testing branch (commit 22f4955340fc).
> >
> > This patchset is marked as RFC because I expect there will be
> > suggestions for possible NFSD implementation improvements.
> >
> > All review appreciated, thanks.
> > Mike
> >
> > v2: rebased v1 ontop of nfsd-testing commit 22f4955340fc
> >
> > Mike Snitzer (11):
> >   exportfs: add ability to advertise NFSv4 ACL passthru support
> >   NFSD: factor out nfsd_supports_nfs4_acl() to nfsd/acl.h
> >   NFS/NFSD: data structure enablement for nfs4_acl passthru support
> >   NFSD: prepare to support SETACL nfs4_acl passthru
> >   NFSD: add NFS4 reexport support for SETACL nfs4_acl passthru
> >   NFSD: add NFS4 reexport support for GETACL nfs4_acl passthru
> >   NFSD: add NFS4ACL_DACL and NFS4ACL_SACL passthru support
> >   NFSD: avoid extra nfs4_acl passthru work unless needed
> >   NFSv4: add reexport support for SETACL nfs4_acl passthru
> >   NFSv4: add reexport support for GETACL nfs4_acl passthru
> >   NFSv4: set EXPORT_OP_NFSV4_ACL_PASSTHRU flag
> >
> >  fs/nfs/export.c          |  23 ++++-
> >  fs/nfs/nfs4proc.c        | 112 +++++++++++++++-------
> >  fs/nfs/nfs4xdr.c         |   2 +-
> >  fs/nfsd/acl.h            |  11 ++-
> >  fs/nfsd/nfs4acl.c        |  69 +++++++++++++-
> >  fs/nfsd/nfs4proc.c       |  32 +++++--
> >  fs/nfsd/nfs4xdr.c        | 194 +++++++++++++++++++++++++++++++++------
> >  fs/nfsd/nfsd.h           |   5 +-
> >  fs/nfsd/xdr4.h           |   2 +
> >  include/linux/exportfs.h |  22 +++++
> >  include/linux/nfs4.h     |  23 ++++-
> >  include/linux/nfs_xdr.h  |  11 +--
> >  include/linux/nfsacl.h   |   7 ++
> >  13 files changed, 431 insertions(+), 82 deletions(-)
> >
> > -- 
> > 2.44.0
> 
> So what you want is indeed pass-through, it's not support for
> local file systems with NFSv4 ACL. NFSD is not only leaving the
> ACEs alone, but it is also not doing any idmapping... and the
> NFS client currently has nothing at all that deals with NFSv4
> ACLs. So that explains the raw byte pass-through design.

Yes, I'm using the NFSv4 ACL payload that is provided by the NFSv4
client. And then NFSD passes that through to the NFSv4 client it is
reexporting.
 
> Passing pages of raw wire data between client and server is
> awkward, however, and has resulted in correctness bugs and
> architectural issues (found during review).

The NFSv4 client goes out of its way to be a passthrough mechanism for
ACLs, because we don't want identity mapping, etc transforming the
payload.

So there is new NFSD code in this series to enable passthru of that
ACL payload from NFSD to NFSv4 client it is reeexporting (because
NFSD's existing limited ACE decode into a list of ACEs is not needed
or useful for passing through to NFSv4 client's existing ACL payload
handling).

> It would be faster for us to start with proper support in NFSD for:
> 
> 6.2.2.  Attribute 58: dacl
> 
>    The dacl attribute is like the acl attribute, but dacl allows just
>    ALLOW and DENY ACEs.  The dacl attribute supports automatic
>    inheritance (see Section 6.4.3.2).
> 
> 6.2.3.  Attribute 59: sacl
> 
>    The sacl attribute is like the acl attribute, but sacl allows just
>    AUDIT and ALARM ACEs.  The sacl attribute supports automatic
>    inheritance (see Section 6.4.3.2).
> 
> This subfeature can get worked out and merged while we sort through
> the API contract issues with ACL pass-through.

This would be useful for NFSD's benefit if native DACL and SACL
support were the goal. But I don't yet see how it helps the reexport
pass-through case my series is focused on. Given the way the NFSv4
client handles ACLs, any extra NFSD processing into intermediate ACLs
actively works against ACL support for the NFSv4 reexport usecase.

> Current NFSD support for DACL/SACL:
> 
> - FATTR4_DACL (bit 58) and FATTR4_SACL (bit 59) are defined in
>   `include/uapi/linux/nfs4.h` but not in any supported attrs mask
> - Dispatch table (`fs/nfsd/nfs4xdr.c`):
>       [FATTR4_DACL] = nfsd4_encode_fattr4__noop,
>       [FATTR4_SACL] = nfsd4_encode_fattr4__noop,
> - Not decoded in nfsd4_decode_fattr4()
> - Not in NFSD_WRITEABLE_ATTRS_WORD1 (`fs/nfsd/nfsd.h`)
> 
> Patch sequence might look something like:
> 
>  1. NFSD: add acl_flags to struct nfs4_acl for nfsacl41
>  2. NFSD: add DACL/SACL decode at correct fattr4 bit position
>  3. NFSD: handle nfsacl41 wire format (aclflag4 + aces) in decode
>  4. NFSD: add nfsacl41 encode for DACL/SACL responses
>  5. NFSD: clear ACL, DACL, and SACL together in supported_attrs
>  6. NFSD: add DACL/SACL to supported and writable attribute masks
> 
> 
> For the API between NFSD and the local NFS client, I might favor an
> alternative to new export operations: NFSD can set "system.nfs4_acl"
> xattrs on NFS client inodes. The only issue there is it limits the
> total number of bytes to 64K. But we can worry about that once the
> DACL/SACL attributes are implemented.

This line of work _seems_ outside the scope of what is needed, so I
won't be pursuing it unless you can help me better understand how this
stepping stone of NFSD having native support for DACL and SACL will
begin to offer more capable ACL pass-through support for NFS reexport.

Further review of the code provided in this series would be
appreciated. I do think I've captured the essence of what is needed.

Thanks,
Mike