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@xxxxxxxxxxxxxxx
