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:     "Benjamin Coddington" <bcodding@redhat.com>,
        "Steve Dickson" <SteveD@RedHat.com>,
        "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>,
        "Trond Myklebust" <trondmy@hammerspace.com>
Subject: Re: [PATCH v2] nfs.man: document requirements for NFSv4 identity
In-reply-to: <9D0A7A61-BCF4-4A1B-B462-5F1402EE0B2E@oracle.com>
References: <164721984672.11933.15475930163427511814@noble.neil.brown.name>,
 <ED6618CE-EC09-448D-904C-F34FCE8E8935@oracle.com>,
 <164730488811.11933.18315180827167871419@noble.neil.brown.name>,
 <9A7BF2ED-E125-4FEF-B984-C343C9E142F0@oracle.com>,
 <164756881642.24302.4153094189268832687@noble.neil.brown.name>,
 <9D0A7A61-BCF4-4A1B-B462-5F1402EE0B2E@oracle.com>
Date:   Mon, 21 Mar 2022 13:14:29 +1100
Message-id: <164782886934.24302.3305618822276162890@noble.neil.brown.name>
Precedence: bulk

On Sat, 19 Mar 2022, Chuck Lever III wrote:
> 
> Here are some suggestions that might make it simpler to implement.
> 
> 1. Ben's tool manufactures the uniqifier if the file doesn't
>    already exist. That seems somewhat racy. Instead, why not
>    make installation utilities responsible for creating the
>    uniquifier? We need some guarantee that when a VM is cloned,
>    the uniquifier is replaced, for instance; that's well
>    outside nfs-utils' sphere of influence.

You say "the file" like that is a well defined concept.  It isn't.
In the context of a container we don't even know if there is *any*
stable local storage.
The existence of "the file" is as much out side of nfs-util's sphere of
influence as the cloning of a VM is.
At least the cloning of a VM is, or soon will be
(https://lwn.net/Articles/887207/), within the sphere of influence of
the NFS kernel module.  It will be able to detect the fork and ....  do
something.  Maybe disable access to all existing mounts and refuse new
mounts until 'identity' has been set.

If NFS had always required identity to be set in a container before
allowing mounts, then the udev approach could work and we would be in a
much better place.  But none of us knew that then, and it is too late
for that now (is it?).

This conversation seems to be going around in circles and not getting
anywhere.  As as I have no direct interest (the SUSE bugzilla has
precisely 1 bug relating to NFS and non-unique hostnames, and the
customer seemed to accept the requirement of unique hostnames) I am
going to bow out.  I might post one more attempt at a documentation
update ... or I might not.

Thanks,
NeilBrown