From: Chuck Lever <chuck.lever@oracle.com>
To: Scott Mayhew <smayhew@redhat.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:36:43 -0400 [thread overview]
Message-ID: <ba8cc0ad-29f7-4064-8405-95f17ac46c64@oracle.com> (raw)
In-Reply-To: <aJIV6I5MNYOU1YQC@aion>
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?
>>> +
>>> + 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
next prev parent reply other threads:[~2025-08-05 14:36 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 [this message]
2025-08-05 14:51 ` Scott Mayhew
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=ba8cc0ad-29f7-4064-8405-95f17ac46c64@oracle.com \
--to=chuck.lever@oracle.com \
--cc=Dai.Ngo@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=smayhew@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