On Sat, 22 Mar 2025, Olga Kornievskaia wrote:
> 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 series address 3 problems.
>
> The first patch addresses a problem related to a TLS export
> policy. NLM call 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.
>
> The other 2 patches are for problems related to sec=krb5.
> The 2nd patch 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 patch 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.
>
> Olga Kornievskaia (3):
> nfsd: fix access checking for NLM under XPRTSEC policies
I agree with this patch
Reviewed-by: NeilBrown <neil@xxxxxxxxxx>
> nfsd: adjust nfsd4_spo_must_allow checking order
I don't disagree with this patch but I don't think it is the best fix.
I've posted an alternate fix. It would be OK for both to go in.
> nfsd: reset access mask for NLM calls in nfsd_permission
I don't like this one. I've explained why separately.
Thanks,
NeilBrown
>
> fs/nfsd/export.c | 20 ++++++++++----------
> fs/nfsd/vfs.c | 7 +++++++
> 2 files changed, 17 insertions(+), 10 deletions(-)
>
> --
> 2.47.1
>
>
>
