From: Jeff Layton <jlayton@kernel.org>
To: Olga Kornievskaia <okorniev@redhat.com>, chuck.lever@oracle.com
Cc: linux-nfs@vger.kernel.org, neilb@suse.de, Dai.Ngo@oracle.com,
tom@talpey.com
Subject: Re: [PATCH 2/3] nfsd: adjust nfsd4_spo_must_allow checking order
Date: Mon, 07 Apr 2025 11:36:07 -0400 [thread overview]
Message-ID: <8556bbf14b11dcb29798374d93f6da27bd1735b7.camel@kernel.org> (raw)
In-Reply-To: <20250322001306.41666-3-okorniev@redhat.com>
On Fri, 2025-03-21 at 20:13 -0400, Olga Kornievskaia wrote:
> Prior to this patch, some non-4.x NFS operations such as NLM
> calls have to go thru export policy checking would end up
> calling nfsd4_spo_must_allow() function and lead to an
> out-of-bounds error because no compound state structures
> needed by nfsd4_spo_must_allow() are present in the svc_rqst
> request structure.
>
> Instead, do the nfsd4_spo_must_allow() checking after the
> may_bypass_gss check which is geared towards allowing various
> calls such as NLM while export policy is set with sec=krb5:...
>
> Fixes: 4cc9b9f2bf4d ("nfsd: refine and rename NFSD_MAY_LOCK")
> Signed-off-by: Olga Kornievskaia <okorniev@redhat.com>
> ---
> fs/nfsd/export.c | 17 ++++++++---------
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
> index 88ae410b4113..02f26cbd59d0 100644
> --- a/fs/nfsd/export.c
> +++ b/fs/nfsd/export.c
> @@ -1143,15 +1143,6 @@ __be32 check_nfsd_access(struct svc_export *exp, struct svc_rqst *rqstp,
> return nfs_ok;
> }
>
> - /* If the compound op contains a spo_must_allowed op,
> - * it will be sent with integrity/protection which
> - * will have to be expressly allowed on mounts that
> - * don't support it
> - */
> -
> - if (nfsd4_spo_must_allow(rqstp))
> - return nfs_ok;
> -
> /* Some calls may be processed without authentication
> * on GSS exports. For example NFS2/3 calls on root
> * directory, see section 2.3.2 of rfc 2623.
> @@ -1168,6 +1159,14 @@ __be32 check_nfsd_access(struct svc_export *exp, struct svc_rqst *rqstp,
> return 0;
> }
> }
> + /* If the compound op contains a spo_must_allowed op,
> + * it will be sent with integrity/protection which
> + * will have to be expressly allowed on mounts that
> + * don't support it
> + */
> + if (nfsd4_spo_must_allow(rqstp))
> + return nfs_ok;
> +
>
> denied:
> return nfserr_wrongsec;
Is this enough to fully fix the OOB problem? It looks like you could
still get past the may_bypass_gss if statement above this with a
carefully crafted RPC.
Maybe the right fix is to make nfsd4_spo_must_allow() check the rq_prog
and rq_vers fields to ensure that this is NFSv4? It can just return
false if it's not.
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2025-04-07 15:36 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-22 0:13 [PATCH 0/3] access checking fixes for NLM under security policies Olga Kornievskaia
2025-03-22 0:13 ` [PATCH 1/3] nfsd: fix access checking for NLM under XPRTSEC policies Olga Kornievskaia
2025-04-07 19:44 ` Jeff Layton
2025-03-22 0:13 ` [PATCH 2/3] nfsd: adjust nfsd4_spo_must_allow checking order Olga Kornievskaia
2025-04-07 15:36 ` Jeff Layton [this message]
2025-04-07 15:56 ` Olga Kornievskaia
2025-04-07 15:59 ` Jeff Layton
2025-04-07 17:17 ` Olga Kornievskaia
2025-04-07 17:47 ` Jeff Layton
2025-04-07 18:02 ` Olga Kornievskaia
2025-03-22 0:13 ` [PATCH 3/3] nfsd: reset access mask for NLM calls in nfsd_permission Olga Kornievskaia
2025-03-27 23:54 ` NeilBrown
2025-03-28 0:36 ` Olga Kornievskaia
2025-03-28 1:43 ` NeilBrown
2025-03-28 12:43 ` Chuck Lever
2025-03-28 15:13 ` Olga Kornievskaia
2025-03-28 21:53 ` NeilBrown
2025-03-28 23:29 ` Tom Talpey
2025-03-30 16:17 ` Chuck Lever
2025-03-30 16:12 ` Olga Kornievskaia
2025-03-31 0:10 ` NeilBrown
2025-03-31 14:49 ` Chuck Lever
2025-03-31 18:24 ` Olga Kornievskaia
2025-04-01 22:24 ` NeilBrown
2025-04-01 22:57 ` Olga Kornievskaia
2025-04-01 23:18 ` NeilBrown
2025-04-07 15:57 ` Jeff Layton
2025-04-08 20:40 ` Benjamin Coddington
2025-03-22 15:08 ` [PATCH 0/3] access checking fixes for NLM under security policies cel
2025-03-28 0:07 ` 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=8556bbf14b11dcb29798374d93f6da27bd1735b7.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--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