Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Chuck Lever III" <chuck.lever@oracle.com>
Cc:     "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] Documentation: Add an explanation of NFSv4 client identifiers
In-reply-to: <4918188E-9271-47F2-8F5A-D6D5BEB85F36@oracle.com>
References: <164970912423.2037.12497015321508491456.stgit@bazille.1015granger.net>,
 <164974719723.11576.583440068909686735@noble.neil.brown.name>,
 <4918188E-9271-47F2-8F5A-D6D5BEB85F36@oracle.com>
Date:   Thu, 14 Apr 2022 14:13:17 +1000
Message-id: <164990959799.11576.7740616159032491033@noble.neil.brown.name>
Precedence: bulk

On Wed, 13 Apr 2022, Chuck Lever III wrote:
> 
> > On Apr 12, 2022, at 3:06 AM, NeilBrown <neilb@suse.de> wrote:
> > 
> > On Tue, 12 Apr 2022, Chuck Lever wrote:
> >> +
> >> +If a client's "co_ownerid" string or principal are not stable,
> >> +state recovery after a server or client reboot is not guaranteed.
> >> +If a client unexpectedly restarts but presents a different
> >> +"co_ownerid" string or principal to the server, the server orphans
> >> +the client's previous open and lock state. This blocks access to
> >> +locked files until the server removes the orphaned state.
> >> +
> >> +If the server restarts and a client presents a changed "co_ownerid"
> >> +string or principal to the server, the server will not allow the
> >> +client to reclaim its open and lock state, and may give those locks
> >> +to other clients in the mean time. This is referred to as "lock
> >> +stealing".
> > 
> > This is not a possible scenario with Linux NFS client.  The client
> > assembles the string once from various sources, then uses it
> > consistently at least until unmount or reboot.  Is it worth mentioning?
> 
> Neil, thanks for the eyes-on. I've integrated the other suggestions
> in your reply. However there are some corner cases here that I'd
> like to consider before proceeding.
> 
> Generally, preserving the cl_owner_id string is good defense against
> lock stealing. Looks like the Linux NFS client didn't do that before
> ceb3a16c070c ("NFSv4: Cache the NFSv4/v4.1 client owner_id in the
> struct nfs_client").
> 
> If a server filesystem is migrated to a server that the client hasn't
> contacted before, and the client's uniquifier or hostname has changed
> since the client established its lease with the first server, there
> is the possibility of lock stealing during transparent state migration.
> 
> I'm also not certain how the Linux NFS client preserves the principal
> that was used when a lease is first established. It's going to use
> Kerberos if possible, but what if the kernel's cred cache expires and
> the keytab has been altered in the meantime? I haven't walked through
> that code carefully enough to understand whether there is still a
> vulnerability.
> 

I don't think id stability relates to lock stealing.

- global uniqueness guards against stealing
- stability guards against misplacing locks during migration ("stolen"
- seems an inappropriate term as no entity an be blamed for stealing).

Certainly stability of both the identity and the credential are
important.  If that stability is not provided then that is a kernel bug.
As you say, ceb3a16c070c fixed a bug in this area.
I don't think this document is an appropriate place to warn against
kernel bugs - that doesn't fit with the purpose given in the intro.

I don't know know if the credential can change either - I hope not.
IF the credential can actually change, that would be a kernel bug.
IF the same credential cannot be renewed, that is a separate problem,
but should be treated like any other credential that cannot be renewed.

I won't argue strongly against this text - I just don't see how it is
appropriate and think it could be confusing.

Thanks,
NeilBrown