> On Nov 12, 2024, at 6:13 PM, NeilBrown <neilb@xxxxxxx> wrote:
>
> On Wed, 13 Nov 2024, Chuck Lever wrote:
>> On Tue, Nov 12, 2024 at 11:49:30AM +1100, NeilBrown wrote:
>>>>
>>>> If you have a specific idea for the mechanism we need to create to
>>>> detect the v3 client reconnects to the server please let me know.
>>>> Reusing or augmenting an existing thing is fine by me.
>>>
>>> nfs3_local_probe(struct nfs_server *server)
>>> {
>>> struct nfs_client *clp = server->nfs_client;
>>> nfs_uuid_t *nfs_uuid = &clp->cl_uuid;
>>>
>>> if (nfs_uuid->connect_cookie != clp->cl_rpcclient->cl_xprt->connect_cookie)
>>> nfs_local_probe_async()
>>> }
>>>
>>> static void nfs_local_probe_async_work(struct work_struct *work)
>>> {
>>> struct nfs_client *clp = container_of(work, struct nfs_client,
>>> cl_local_probe_work);
>>> clp->cl_uuid.connect_cookie =
>>> clp->cl_rpcclient->cl_xprt->connect_cookie;
>>> nfs_local_probe(clp);
>>> }
>>>
>>> Or maybe assign connect_cookie (which we have to add to uuid) inside
>>> nfs_local_probe().
>>
>> The problem with per-connection checks is that a change in export
>> security policy could disable LOCALIO rather persistently. The only
>> way to recover, if checking is done only when a connection is
>> established, is to remount or force a disconnect.
>>
> What export security policy specifically?
> Do you mean changing from sec=sys to to sec=krb5i for example?
Another example might be altering the IP address list on
the export. Suppose the client is accidentally blocked
by this policy, the administrator realizes it, and changes
it again to restore access.
The client does not disconnect in this case, AFAIK.
> This
> would (hopefully) disable localio. Then changing the export back to
> sec=sys would mean that localio would be possible again. I wonder how
> the client copes with this. Does it work on a live mount without
> remount? If so it would certainly make sense for the current security
> setting to be cached in nfs_uidd and for a probe to be attempted
> whenever that changed to sec=sys.
>
> Thanks,
> NeilBrown
--
Chuck Lever
