From: Mike Snitzer <snitzer@kernel.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org, Jeff Layton <jlayton@kernel.org>,
Anna Schumaker <anna@kernel.org>,
Trond Myklebust <trondmy@hammerspace.com>,
NeilBrown <neilb@suse.de>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v13 04/19] nfsd: factor out __fh_verify to allow NULL rqstp to be passed
Date: Tue, 27 Aug 2024 15:35:38 -0400 [thread overview]
Message-ID: <Zs4qisuA5WeGcsOI@kernel.org> (raw)
In-Reply-To: <Zs4obErc91MR/Kfu@tissot.1015granger.net>
On Tue, Aug 27, 2024 at 03:26:36PM -0400, Chuck Lever wrote:
> On Tue, Aug 27, 2024 at 02:58:21PM -0400, Mike Snitzer wrote:
> > On Sun, Aug 25, 2024 at 11:32:50AM -0400, Chuck Lever wrote:
> > > On Fri, Aug 23, 2024 at 02:14:02PM -0400, Mike Snitzer wrote:
> > > > From: NeilBrown <neilb@suse.de>
> > > >
> > > > __fh_verify() offers an interface like fh_verify() but doesn't require
> > > > a struct svc_rqst *, instead it also takes the specific parts as
> > > > explicit required arguments. So it is safe to call __fh_verify() with
> > > > a NULL rqstp, but the net, cred, and client args must not be NULL.
> > > >
> > > > __fh_verify() does not use SVC_NET(), nor does the functions it calls.
> > > >
> > > > Rather then depending on rqstp->rq_vers to determine nfs version, pass
> > > > it in explicitly. This removes another dependency on rqstp and ensures
> > > > the correct version is checked. The rqstp can be for an NLM request and
> > > > while some code tests that, other code does not.
> > > >
> > > > Rather than using rqstp->rq_client pass the client and gssclient
> > > > explicitly to __fh_verify and then to nfsd_set_fh_dentry().
> > > >
> > > > The final places where __fh_verify unconditionally dereferences rqstp
> > > > involve checking if the connection is suitably secure. They look at
> > > > rqstp->rq_xprt which is not meaningful in the target use case of
> > > > "localio" NFS in which the client talks directly to the local server.
> > > > So have these always succeed when rqstp is NULL.
> > > >
> > > > Lastly, 4 associated tracepoints are only used if rqstp is not NULL
> > > > (this is a stop-gap that should be properly fixed so localio also
> > > > benefits from the utility these tracepoints provide when debugging
> > > > fh_verify issues).
> > > >
> > > > Signed-off-by: NeilBrown <neilb@suse.de>
> > > > Co-developed-by: Mike Snitzer <snitzer@kernel.org>
> > > > Signed-off-by: Mike Snitzer <snitzer@kernel.org>
> > >
> > > IMO this patch needs to be split up. There are several changes that
> > > need separate explanation and rationale, and the changes here need
> > > to be individually bisectable.
> > >
> > > If you prefer, I can provide a patch series that replaces this one
> > > patch, or Neil could provide it if he wants.
> >
> > I'm probably not the best person to take a crack at splitting this
> > patch up.
> >
> > Neil initially had factored out N patches, but they weren't fully
> > baked so when I had to fix the code up it became a challenge to
> > sprinkle fixes across the N patches. Because they were all
> > pretty interdependent.
> >
> > In the end, all these changes are in service to allowing for the
> > possibility that the rqstp not available (NULL). So it made sense to
> > fold them together.
> >
> > I really don't see how factoring these changes out to N patches makes
> > them useful for bisection (you need all of them to test the case when
> > rqstp is NULL, and a partial application of changes to track down a
> > rqstp-full regression really isn't such a concern given fh_verify()
> > fully passes all args to __fh_verify so status-quo preserved).
> >
> > All said, if your intuition and experience makes you feel splitting
> > this patch up is needed then I'm fine with it and I welcome your or
> > Neil's contribtion. It is fiddley work though, so having had my own
> > challenges with the code when these changes were split out makes me
> > hesitant to jump on splitting them out again.
> >
> > Hope I've explained myself clearly... not being confrontational,
> > dismissive or anything else. ;)
>
> True, this isn't an enormous single patch, but you gotta draw that
> line somewhere.
>
> The goal is to make these changes as small and atomic as possible so
> it becomes easy to spot a mistake or bisect to find unintended
> behavior introduced in the non-LOCALIO case. This is a code path
> that is heavily utilized by NFSD so it pays to take some defensive
> precautions.
>
> Generally I find that a typo or hidden assumption magically appears
> when I've engaged in this kind of refactoring exercise. I've got a
> good toolchain that should make this quick work.
Awesome.
> > > > --- a/fs/nfsd/export.c
> > > > +++ b/fs/nfsd/export.c
> > > > @@ -1077,7 +1077,13 @@ static struct svc_export *exp_find(struct cache_detail *cd,
> > > > __be32 check_nfsd_access(struct svc_export *exp, struct svc_rqst *rqstp)
> > > > {
> > > > struct exp_flavor_info *f, *end = exp->ex_flavors + exp->ex_nflavors;
> > > > - struct svc_xprt *xprt = rqstp->rq_xprt;
> > > > + struct svc_xprt *xprt;
> > > > +
> > > > + if (!rqstp)
> > > > + /* Always allow LOCALIO */
> > > > + return 0;
> > > > +
> > > > + xprt = rqstp->rq_xprt;
> > >
> > > check_nfsd_access() is a public API, so it needs a kdoc comment.
> > >
> > > These changes should be split into a separate patch with a clear
> > > rationale of why "Always allow LOCALIO" is secure and appropriate
> > > to do.
> >
> > Separate patch aside, I'll try to improve that comment.
>
> Post the comment update here and I can work that in.
Here is the incremental patch:
diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
index fe36f441d1d9..8b54f66f0e0f 100644
--- a/fs/nfsd/export.c
+++ b/fs/nfsd/export.c
@@ -1074,14 +1074,26 @@ static struct svc_export *exp_find(struct cache_detail *cd,
return exp;
}
+/**
+ * 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).
+ *
+ * Returns 0 if access is granted or nfserr_wrongsec if access is denied.
+ */
__be32 check_nfsd_access(struct svc_export *exp, struct svc_rqst *rqstp)
{
struct exp_flavor_info *f, *end = exp->ex_flavors + exp->ex_nflavors;
struct svc_xprt *xprt;
- if (!rqstp)
- /* Always allow LOCALIO */
+ if (!rqstp) {
+ /*
+ * The target use case for rqstp being NULL is LOCALIO,
+ * which only supports AUTH_UNIX, so always allow LOCALIO
+ * because the other checks below aren't applicable.
+ */
return 0;
+ }
xprt = rqstp->rq_xprt;
next prev parent reply other threads:[~2024-08-27 19:35 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-23 18:13 [PATCH v13 00/19] nfs/nfsd: add support for localio Mike Snitzer
2024-08-23 18:13 ` [PATCH v13 01/19] nfs_common: factor out nfs_errtbl and nfs_stat_to_errno Mike Snitzer
2024-08-23 18:14 ` [PATCH v13 02/19] nfs_common: factor out nfs4_errtbl and nfs4_stat_to_errno Mike Snitzer
2024-08-23 18:14 ` [PATCH v13 03/19] nfs: factor out {encode,decode}_opaque_fixed to nfs_xdr.h Mike Snitzer
2024-08-23 18:14 ` [PATCH v13 04/19] nfsd: factor out __fh_verify to allow NULL rqstp to be passed Mike Snitzer
2024-08-25 15:32 ` Chuck Lever
2024-08-25 23:44 ` NeilBrown
2024-08-26 14:51 ` Chuck Lever
2024-08-28 17:01 ` Chuck Lever
2024-08-29 0:30 ` Mike Snitzer
2024-08-29 0:32 ` Mike Snitzer
2024-08-27 18:58 ` Mike Snitzer
2024-08-27 19:26 ` Chuck Lever
2024-08-27 19:35 ` Mike Snitzer [this message]
2024-08-23 18:14 ` [PATCH v13 05/19] nfsd: add nfsd_file_acquire_local() Mike Snitzer
2024-08-25 15:18 ` Chuck Lever
2024-08-23 18:14 ` [PATCH v13 06/19] SUNRPC: remove call_allocate() BUG_ONs Mike Snitzer
2024-08-23 18:14 ` [PATCH v13 07/19] SUNRPC: add rpcauth_map_clnt_to_svc_cred_local Mike Snitzer
2024-08-25 15:17 ` Chuck Lever
2024-08-27 16:08 ` Mike Snitzer
2024-08-23 18:14 ` [PATCH v13 08/19] SUNRPC: replace program list with program array Mike Snitzer
2024-08-25 15:14 ` Chuck Lever
2024-08-23 18:14 ` [PATCH v13 09/19] nfs_common: add NFS LOCALIO auxiliary protocol enablement Mike Snitzer
2024-08-26 0:32 ` NeilBrown
2024-08-27 17:45 ` Mike Snitzer
2024-08-27 21:25 ` NeilBrown
2024-08-23 18:14 ` [PATCH v13 10/19] nfsd: add localio support Mike Snitzer
2024-08-25 15:13 ` Chuck Lever
2024-08-26 0:53 ` NeilBrown
2024-08-26 20:03 ` Mike Snitzer
2024-08-23 18:14 ` [PATCH v13 11/19] nfsd: implement server support for NFS_LOCALIO_PROGRAM Mike Snitzer
2024-08-25 15:09 ` Chuck Lever
2024-08-23 18:14 ` [PATCH v13 12/19] nfs: pass struct nfsd_file to nfs_init_pgio and nfs_init_commit Mike Snitzer
2024-08-23 18:14 ` [PATCH v13 13/19] nfs: add localio support Mike Snitzer
2024-08-26 1:21 ` NeilBrown
2024-08-23 18:14 ` [PATCH v13 14/19] nfs: enable localio for non-pNFS IO Mike Snitzer
2024-08-23 18:14 ` [PATCH v13 15/19] pnfs/flexfiles: enable localio support Mike Snitzer
2024-08-26 1:39 ` NeilBrown
2024-08-26 15:38 ` Mike Snitzer
2024-08-27 21:27 ` NeilBrown
2024-08-23 18:14 ` [PATCH v13 16/19] nfs/localio: use dedicated workqueues for filesystem read and write Mike Snitzer
2024-08-23 18:14 ` [PATCH v13 17/19] nfs: implement client support for NFS_LOCALIO_PROGRAM Mike Snitzer
2024-08-23 18:14 ` [PATCH v13 18/19] nfs: add Documentation/filesystems/nfs/localio.rst Mike Snitzer
2024-08-23 18:14 ` [PATCH v13 19/19] nfs: add FAQ section to Documentation/filesystems/nfs/localio.rst Mike Snitzer
2024-08-26 1:56 ` NeilBrown
2024-08-26 14:16 ` Chuck Lever III
2024-08-26 14:50 ` Trond Myklebust
2024-08-27 21:49 ` NeilBrown
2024-08-27 22:24 ` Trond Myklebust
2024-08-27 23:41 ` NeilBrown
2024-08-28 0:08 ` Trond Myklebust
2024-08-28 4:26 ` Mike Snitzer
2024-08-25 15:46 ` [PATCH v13 00/19] nfs/nfsd: add support for localio Chuck Lever
2024-08-27 16:56 ` Mike Snitzer
2024-08-26 1:59 ` NeilBrown
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=Zs4qisuA5WeGcsOI@kernel.org \
--to=snitzer@kernel.org \
--cc=anna@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=trondmy@hammerspace.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;
as well as URLs for NNTP newsgroup(s).