Linux NFS development
 help / color / mirror / Atom feed
From: Scott Mayhew <smayhew@redhat.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: jlayton@kernel.org, neil@brown.name, okorniev@redhat.com,
	Dai.Ngo@oracle.com, tom@talpey.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH] nfsd: decouple the xprtsec policy check from check_nfsd_access()
Date: Tue, 5 Aug 2025 10:51:47 -0400	[thread overview]
Message-ID: <aJIag6X9YdeebM-s@aion> (raw)
In-Reply-To: <ba8cc0ad-29f7-4064-8405-95f17ac46c64@oracle.com>

On Tue, 05 Aug 2025, Chuck Lever wrote:

> On 8/5/25 10:32 AM, Scott Mayhew wrote:
> > On Fri, 01 Aug 2025, Chuck Lever wrote:
> > 
> >> On 7/31/25 5:14 PM, Scott Mayhew wrote:
> 
> >>> +}
> >>> +
> >>> +/**
> >>> + * check_nfsd_access - check if access to export is allowed.
> >>> + * @exp: svc_export that is being accessed.
> >>> + * @rqstp: svc_rqst attempting to access @exp (will be NULL for LOCALIO).
> >>> + * @may_bypass_gss: reduce strictness of authorization check
> >>> + *
> >>> + * Return values:
> >>> + *   %nfs_ok if access is granted, or
> >>> + *   %nfserr_wrongsec if access is denied
> >>> + */
> >>> +__be32 check_nfsd_access(struct svc_export *exp, struct svc_rqst *rqstp,
> >>> +			 bool may_bypass_gss)
> >>> +{
> >>> +	struct exp_flavor_info *f, *end = exp->ex_flavors + exp->ex_nflavors;
> >>> +	struct svc_xprt *xprt;
> >>> +
> >>> +	/*
> >>> +	 * If rqstp is NULL, this is a LOCALIO request which will only
> >>> +	 * ever use a filehandle/credential pair for which access has
> >>> +	 * been affirmed (by ACCESS or OPEN NFS requests) over the
> >>> +	 * wire. So there is no need for further checks here.
> >>> +	 */
> >>> +	if (!rqstp)
> >>> +		return nfs_ok;
> >>
> >> Is this true of all of check_nfsd_access's callers, or only of
> >> __fh_verify ?
> >>
> > Looking at the commit where this check was added, and looking at the
> > other callers, it looks like this is only true of __fh_verify().
> > 
> > I'm splitting up check_nfsd_access() into two helpers has you suggested,
> > having __fh_verify() call the helpers directly while having the other
> > callers continue to use check_nfsd_access().
> > 
> > Should I add an argument to the helpers indicate when they have been
> > called directly?  Something like 'bool maybe_localio', which can
> > then be incorporated into the above check, e.g.
> > 
> >         if (!rqstp) {
> >                 if (maybe_localio) {
> >                         return nfs_ok;
> >                 } else {
> >                         WARN_ON_ONCE(1);
> >                         return nfserr_wrongsec;
> >                 }
> >         }
> 
> If __fh_verify is the only call site that can invoke these helpers with
> rqstp == NULL, then __fh_verify seems like the place to do this check,
> not in the helpers. But maybe I've misunderstood something?

No, that makes sense.  Thanks.
> 
> 
> >>> +
> >>> +	xprt = rqstp->rq_xprt;
> >>> +
> >>>  	/* legacy gss-only clients are always OK: */
> >>>  	if (exp->ex_client == rqstp->rq_gssclient)
> >>>  		return nfs_ok;
> >>> @@ -1167,7 +1202,6 @@ __be32 check_nfsd_access(struct svc_export *exp, struct svc_rqst *rqstp,
> >>>  		}
> >>>  	}
> >>>  
> >>> -denied:
> >>>  	return nfserr_wrongsec;
> >>>  }
> >>>  
> 
> 
> -- 
> Chuck Lever
> 


      reply	other threads:[~2025-08-05 14:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-31 21:14 [PATCH] nfsd: decouple the xprtsec policy check from check_nfsd_access() Scott Mayhew
2025-07-31 21:49 ` Scott Mayhew
2025-08-01  1:53 ` NeilBrown
2025-08-01 10:23 ` kernel test robot
2025-08-01 13:00 ` Jeff Layton
2025-08-01 13:24 ` Chuck Lever
2025-08-05 14:32   ` Scott Mayhew
2025-08-05 14:36     ` Chuck Lever
2025-08-05 14:51       ` Scott Mayhew [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aJIag6X9YdeebM-s@aion \
    --to=smayhew@redhat.com \
    --cc=Dai.Ngo@oracle.com \
    --cc=chuck.lever@oracle.com \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=tom@talpey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox