From: Olga Kornievskaia <okorniev@redhat.com>
To: chuck.lever@oracle.com, jlayton@kernel.org
Cc: linux-nfs@vger.kernel.org, neilb@suse.de, Dai.Ngo@oracle.com,
tom@talpey.com, Olga Kornievskaia <okorniev@redhat.com>
Subject: [PATCH 1/1] nfsd: fix NLM access checking
Date: Wed, 19 Mar 2025 17:46:41 -0400 [thread overview]
Message-ID: <20250319214641.27699-1-okorniev@redhat.com> (raw)
Since commit 4cc9b9f2bf4df ("nfsd: refine and rename NFSD_MAY_LOCK")
for export policies with "sec=krb5:..." or "xprtsec=tls:.." NLM
locking calls on v3 mounts fail. And for "sec=krb5" NLM calls it
also leads to out-of-bounds reference while in check_nfsd_access().
This patch does 3 fixes. 2 problems are related to sec=krb5.
First is fixing what "access" content is being passed into
the inode_permission(). Prior to 4cc9b9f2bf4df, the code would
explicitly set access to be read/ownership. And after is passes
access that's set in nlm_fopen but it's lacking read access.
Second is because previously for NLM check_nfsd_access() was
never called and thus nfsd4_spo_must_allow() function wasn't
called. After the patch, this lead to NLM call which has no
compound state structure created trying to dereference it.
This patch instead moves the call to after may_bypass_gss
check which implies NLM and would return there and would
never get to calling nfsd4_spo_must_allow().
The last problem is related to TLS export policy. NLM dont
come over TLS and thus dont pass the TLS checks in
check_nfsd_access() leading to access being denied. Instead
rely on may_bypass_gss to indicate NLM and allow access
checking to continue.
Fixes: 4cc9b9f2bf4df ("nfsd: refine and rename NFSD_MAY_LOCK")
Signed-off-by: Olga Kornievskaia <okorniev@redhat.com>
---
fs/nfsd/export.c | 23 +++++++++++++----------
fs/nfsd/vfs.c | 4 ++++
2 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
index 0363720280d4..4cbf617efa7c 100644
--- a/fs/nfsd/export.c
+++ b/fs/nfsd/export.c
@@ -1124,7 +1124,8 @@ __be32 check_nfsd_access(struct svc_export *exp, struct svc_rqst *rqstp,
test_bit(XPT_PEER_AUTH, &xprt->xpt_flags))
goto ok;
}
- goto denied;
+ if (!may_bypass_gss)
+ goto denied;
ok:
/* legacy gss-only clients are always OK: */
@@ -1142,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 +1160,17 @@ __be32 check_nfsd_access(struct svc_export *exp, struct svc_rqst *rqstp,
}
}
+ /* 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
+ */
+ /* This call must be done after the may_bypass_gss check.
+ * may_bypass_gss implies NLM(/MOUNT) and not 4.1
+ */
+ if (nfsd4_spo_must_allow(rqstp))
+ return nfs_ok;
+
denied:
return nfserr_wrongsec;
}
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 4021b047eb18..95d973136079 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -2600,6 +2600,10 @@ nfsd_permission(struct svc_cred *cred, struct svc_export *exp,
uid_eq(inode->i_uid, current_fsuid()))
return 0;
+ /* If this is NLM, require read or ownership permissions */
+ if (acc & NFSD_MAY_NLM)
+ acc = NFSD_MAY_READ | NFSD_MAY_OWNER_OVERRIDE;
+
/* This assumes NFSD_MAY_{READ,WRITE,EXEC} == MAY_{READ,WRITE,EXEC} */
err = inode_permission(&nop_mnt_idmap, inode,
acc & (MAY_READ | MAY_WRITE | MAY_EXEC));
--
2.47.1
next reply other threads:[~2025-03-19 21:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-19 21:46 Olga Kornievskaia [this message]
2025-03-20 13:55 ` [PATCH 1/1] nfsd: fix NLM access checking Chuck Lever
2025-03-20 16:29 ` Olga Kornievskaia
2025-03-20 17:32 ` Chuck Lever
2025-03-20 20:46 ` Olga Kornievskaia
2025-03-21 13:40 ` Chuck Lever
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=20250319214641.27699-1-okorniev@redhat.com \
--to=okorniev@redhat.com \
--cc=Dai.Ngo@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--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