Re: [PATCH v2 2/3] NFSD/export: Add sign_fh export option

[Jeff Layton <jlayton@kernel.org>]

On Thu, 2026-01-22 at 11:54 -0500, Benjamin Coddington wrote:
> On 22 Jan 2026, at 11:50, Jeff Layton wrote:
> 
> > On Thu, 2026-01-22 at 11:31 -0500, Benjamin Coddington wrote:
> > > On 22 Jan 2026, at 11:02, Jeff Layton wrote:
> > > 
> > > > On Wed, 2026-01-21 at 15:24 -0500, Benjamin Coddington wrote:
> > > > > In order to signal that filehandles on this export should be signed, add a
> > > > > "sign_fh" export option.  Filehandle signing can help the server defend
> > > > > against certain filehandle guessing attacks.
> > > > > 
> > > > > Setting the "sign_fh" export option sets NFSEXP_SIGN_FH.  In a future patch
> > > > > NFSD uses this signal to append a MAC onto filehandles for that export.
> > > > > 
> > > > > While we're in here, tidy a few stray expflags to more closely align to the
> > > > > export flag order.
> > > > > 
> > > > > Link: https://lore.kernel.org/linux-nfs/cover.1769026777.git.bcodding@hammerspace.com
> > > > > Signed-off-by: Benjamin Coddington <bcodding@hammerspace.com>
> > > > > ---
> > > > >  fs/nfsd/export.c                 | 5 +++--
> > > > >  include/uapi/linux/nfsd/export.h | 4 ++--
> > > > >  2 files changed, 5 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
> > > > > index 2a1499f2ad19..19c7a91c5373 100644
> > > > > --- a/fs/nfsd/export.c
> > > > > +++ b/fs/nfsd/export.c
> > > > > @@ -1349,13 +1349,14 @@ static struct flags {
> > > > >  	{ NFSEXP_ASYNC, {"async", "sync"}},
> > > > >  	{ NFSEXP_GATHERED_WRITES, {"wdelay", "no_wdelay"}},
> > > > >  	{ NFSEXP_NOREADDIRPLUS, {"nordirplus", ""}},
> > > > > +	{ NFSEXP_SECURITY_LABEL, {"security_label", ""}},
> > > > > +	{ NFSEXP_SIGN_FH, {"sign_fh", ""}},
> > > > >  	{ NFSEXP_NOHIDE, {"nohide", ""}},
> > > > > -	{ NFSEXP_CROSSMOUNT, {"crossmnt", ""}},
> > > > >  	{ NFSEXP_NOSUBTREECHECK, {"no_subtree_check", ""}},
> > > > >  	{ NFSEXP_NOAUTHNLM, {"insecure_locks", ""}},
> > > > > +	{ NFSEXP_CROSSMOUNT, {"crossmnt", ""}},
> > > > >  	{ NFSEXP_V4ROOT, {"v4root", ""}},
> > > > >  	{ NFSEXP_PNFS, {"pnfs", ""}},
> > > > > -	{ NFSEXP_SECURITY_LABEL, {"security_label", ""}},
> > > > >  	{ 0, {"", ""}}
> > > > >  };
> > > > > 
> > > > > diff --git a/include/uapi/linux/nfsd/export.h b/include/uapi/linux/nfsd/export.h
> > > > > index a73ca3703abb..de647cf166c3 100644
> > > > > --- a/include/uapi/linux/nfsd/export.h
> > > > > +++ b/include/uapi/linux/nfsd/export.h
> > > > > @@ -34,7 +34,7 @@
> > > > >  #define NFSEXP_GATHERED_WRITES	0x0020
> > > > >  #define NFSEXP_NOREADDIRPLUS    0x0040
> > > > >  #define NFSEXP_SECURITY_LABEL	0x0080
> > > > > -/* 0x100 currently unused */
> > > > > +#define NFSEXP_SIGN_FH		0x0100
> > > > >  #define NFSEXP_NOHIDE		0x0200
> > > > >  #define NFSEXP_NOSUBTREECHECK	0x0400
> > > > >  #define	NFSEXP_NOAUTHNLM	0x0800		/* Don't authenticate NLM requests - just trust */
> > > > > @@ -55,7 +55,7 @@
> > > > >  #define NFSEXP_PNFS		0x20000
> > > > > 
> > > > >  /* All flags that we claim to support.  (Note we don't support NOACL.) */
> > > > > -#define NFSEXP_ALLFLAGS		0x3FEFF
> > > > > +#define NFSEXP_ALLFLAGS		0x3FFFF
> > > > > 
> > > > >  /* The flags that may vary depending on security flavor: */
> > > > >  #define NFSEXP_SECINFO_FLAGS	(NFSEXP_READONLY | NFSEXP_ROOTSQUASH \
> > > > 
> > > > One thing that needs to be understood and documented is how things will
> > > > behave when this flag changes. For instance:
> > > > 
> > > > Support we start with sign_fh enabled, and client gets a signed
> > > > filehandle. The server then reboots and the export options change such
> > > > that sign_fh is disabled. What happens when the client tries to present
> > > > that fh to the server? Does it ignore the signature (since sign_fh is
> > > > now disabled), or does it reject the filehandle because it's not
> > > > expecting a signature?
> > > 
> > > That's great question - right now it will first look up the export, see that
> > > NFSEXP_SIGN_FH is not set, then bypass verifying (and truncating) the MAC
> > > from the end of the filehadle before sending the filehandle off to exportfs
> > > - the end result will be will be -ESTALE.
> > > 
> > > Would it be a good idea to allow the server to see that the filehandle has
> > > FH_AT_MAC set, and just trim off the MAC without verifying it?  That would
> > > allow the signed fh to still function on that export.
> > > 
> > > Might need to audit the cases where fh_match() is used in that case, or make
> > > fh_match() signed-aware.  I'm less familiar with those cases, but I can look
> > > into them.
> > > 
> > 
> > No, I think -ESTALE is fine in this situation. I don't think we need to
> > go to any great lengths to make this scenario actually work. We just
> > need to understand what happens if it does, and make sure that it's
> > documented.
> 
> Got it - I will document this behavior in the commit message of the last
> patch on the next posting.  I think I'll probably also add a check for this
> case -- no need to send the filehandle off to the filesystems if we know its
> going to fail to resolve to a dentry.
> 

Consider adding a new section in
Documentation/filesystems/nfs/exporting.rst. Commit messages will be
harder to dig out years from now.
-- 
Jeff Layton <jlayton@kernel.org>