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:     Trond Myklebust <trond.myklebust@hammerspace.com>
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: NFS access problems when group membership changes on server
Date:   Thu, 03 Mar 2022 16:29:37 +1100
Message-id: <164628537738.17899.2312723585718867242@noble.neil.brown.name>
Precedence: bulk


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.

Any other ideas?

Thanks,
NeilBrown