linux-kernel - Re: [PATCH] lockd: don't allow locking on reexported NFSv2/3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <176125614781.1793333.13308972752606421183@noble.neil.brown.name>
Date: Fri, 24 Oct 2025 08:49:07 +1100
From: NeilBrown <neilb@...mail.net>
To: "Jeff Layton" <jlayton@...nel.org>
Cc: "Chuck Lever" <chuck.lever@...cle.com>,
 "Olga Kornievskaia" <okorniev@...hat.com>, "Dai Ngo" <Dai.Ngo@...cle.com>,
 "Tom Talpey" <tom@...pey.com>, "Trond Myklebust" <trondmy@...nel.org>,
 "Anna Schumaker" <anna@...nel.org>, "Mike Snitzer" <snitzer@...nel.org>,
 linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
 "Jeff Layton" <jlayton@...nel.org>
Subject: Re: [PATCH] lockd: don't allow locking on reexported NFSv2/3

On Fri, 24 Oct 2025, Jeff Layton wrote:
> Since commit 9254c8ae9b81 ("nfsd: disallow file locking and delegations
> for NFSv4 reexport"), file locking when reexporting an NFS mount via
> NFSv4 is expressly prohibited by nfsd. Do the same in lockd:
> 
> Add a new  nlmsvc_file_cannot_lock() helper that will test whether file
> locking is allowed for a given file, and return nlm_lck_denied_nolocks
> if it isn't.
> 
> Signed-off-by: Jeff Layton <jlayton@...nel.org>
> ---
> Regardless of how we fix the bug that Olga found recently, I think we
> need to do this as well. We don't allow locking when reexporting via v4,
> and I don't think we want to allow it when reexporting via v2/3 either.

I would like to see more justification.  The two locking protocols have
substantial differences so it is not obvious that reasoning which
applies to one also applies to the other.

What is the reason that we disable locking for v4?  If we could state
that and justify that the same reasoning applies to v3, then certainly
this would be an appropriate fix.

My guess is that it relates to handling restart of the forwarding server
from the perspectives of both the ultimate client and the ultimate
server.  Restart handling is quite different in the two protocols, but
maybe they are equally unable to handle this situation?

Thanks,
NeilBrown