Re: [PATCH 0/2] NFS: limit use of ACCESS cache for negative responses

[Trond Myklebust <trondmy@hammerspace.com>]

On Sat, 2022-09-03 at 19:57 +1000, NeilBrown wrote:
> The whole point of the NFS ACCESS request is that the client cannot
> know
> how to interpret any access controls that the server might have in
> place.  Who knows, they might even be time based access controls
> (games can only be played on the weekend).  Ok, that is a bit
> extreme,
> but the principle remains.
> 
> *You* might "know" that there are two pieces (in this specific
> example)
> and that one doesn't directly relate to the inodes, but the NFS
> client
> doesn't know that.  The NFS client only knows that it can request
> ACCESS
> information for a filehandle in the context of a credential.  The
> Linux
> NFS client then caches that against the inode (so it is all somehow
> related to the inode).
> 
> The spec doesn't give the client permission to cached these details
> AT
> ALL.  Caching positive results makes perfect sense from a performance
> perspective and is easily defensible.  Caching negative results ... 
> not
> so much.

Of course the spec allows the client to cache permissions in both NFSv3
and NFSv4. Otherwise there would be no way we could cache objects at
all. Enabling the client to gate access to cached data such as
directory contents, and cached data without troubling the server is the
whole point of the ACCESS operation. Without that ability, we would
have to ask the server every time a user tried to 'cd' into a
directory, called open(), called getdents(), called read(), called
write(), ... Without that ability, NFSv4 delegations would be
pointless, because we'd have to go and ask the server for all these
operations.
I know the spec is littered with mealy mouthed "The server can revoke
access permission at any time" statements in various spots, but that
looks more like something to placate a review by the IBM legal team
(yes, it happened) rather than a basic assumption that was engineered
into the protocol. The protocol simply cannot work as described in
RFC5661 and RFC7530 without the assumption that you can cache.

The other point is that access cache changes due to AD/LDAP/NIS group
membership updates happen once in a blue moon, and when they do, they
affect _ALL_ cached values for that user, and not just one at a time.
When those things do happen, the user normally expects to have to log
out and then log back in so that the new group memberships are
reflected in that user's cred (as per POSIX prescribed behaviour). That
will cause the NFS client to send new ACCESS calls to the server,
because the new cred will not be found in the existing access cache.
The only case where this assumption fails, is if the server is
implementing the '--manage-gids' behaviour, and caches its
representation of the user's creds past the time when the user logged
out and logged in again.
So this is literally a 1 in a billion chance problem that you're asking
us to fix. Optimising for that case by adding in a timeout that affects
all cached access value is just not in the cards.

I've already sent out a patch that forces realignment of the NFS client
behaviour with that of POSIX by requiring the client to recheck cached
access values for an existing credential after a new login, but does
not add any further impediments to the access cache. Why is that
approach not sufficient?

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com