On Thu, 2022-03-03 at 16:29 +1100, NeilBrown wrote:
>
> Since
> Commit 57b691819ee2 ("NFS: Cache access checks more aggressively")
> we do not recheck "ACCESS" tests unless the inode changes (or falls
> out
> of cache). I recently discovered that this can be problematic.
>
> The ACCESS test checks if a given user has access to a given file.
> That is most likely to change if the file changes, but it can change
> if
> the users capabilities change - e.g. their group memberships change.
> With AUTH_SYS the group membership as seen on the client is used
> (though
> with the Linux NFS server, adding the -g option to mountd can change
> this).
> With AUTH_GSS, the mapping from user to groups must happen on the
> server. IF this mapping changes it might be invisible to the client
> for an arbitrary long time.
>
> I don't think this affects files with NFSv4 as there will be a OPEN
> request to the server, but it does affect directories.
>
> If a user does "ls -l some-directory", this fails, and they go ask
> the
> server admin "please add me to the group to access the directory",
> then
> they go back and try again, it may well still not work.
>
> With a local filesystem, logging off and back on again might be
> required to refresh the groups list, but even this isn't sufficient
> for
> NFS.
>
> What to do?
>
> We could simply revert that patch and refresh the access cache
> similar
> to refreshing of other attributes. We could possibly do it with a
> longer timeout or only with a mount option, but I don't really like
> those options.
>
> Maybe we could add a 'struct pid *' to the access entry which
> references
> the PIDTYPE_SID of the calling process. This would be different for
> different login sessions, but common throughout one login.
> If we did this, then logging out and back in again would resolve the
> access problem, which matches that is needed for local access.
> I'm not sure if I like this idea or not, but I thought it worth
> mentioning.
>
Actually, most of the newer common identity mapping schemes, including
Active Directory and FreeIPA will store the group membership in a PAC,
which is attached to the ticket on the client. So the mapping still
happens on the server, but it uses information from the GSS session
instead of doing another round trip to the identity server.
That means the group membership as understood by the server is tied to
your AUTH_GSS session and the ticket that created it. To change it, you
may need to invalidate the AUTH_GSS session, and change your kerberos
ticket through a new "kinit".
>
> Any other ideas?
>
As I see it, the cache needs to be tied to the GSS ticket so that any
given entry can be invalidated when the ticket is. That's a scheme that
also works just fine for AUTH_SYS, and would exactly preserve the POSIX
semantics whereby we update the group membership on login.
One suggestion for doing so might be to allow the cache entries to
subscribe to the RPC cred that was used to create them in a way that
doesn't prevent the cred from being kicked out of the cache (i.e. we
don't take a reference). If the cred is no longer in the cred cache
when we check the access cache, then consider the access entry to need
refreshing/revalidation.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@xxxxxxxxxxxxxxx
