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: <33776ce60779cd08aca9dd662fa3ac55c895e713.camel@kernel.org>
Date: Thu, 23 Oct 2025 18:41:36 -0400
From: Jeff Layton <jlayton@...nel.org>
To: NeilBrown <neil@...wn.name>
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
Subject: Re: [PATCH] lockd: don't allow locking on reexported NFSv2/3

On Fri, 2025-10-24 at 08:49 +1100, NeilBrown wrote:
> 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?
> 

Yes, that's basically it. If the reexporting server crashes and
reboots, there is no mechanism to force the backend server into grace
and no coordination of their grace periods. That's true for all
versions of NFS.

Documentation/filesystems/nfs/reexport.rst has a section that talks
about reboot recovery which documents this, but we can certainly quote
that in the changelog.
-- 
Jeff Layton <jlayton@...nel.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ