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:     "Benjamin Coddington" <bcodding@redhat.com>
Cc:     "Trond Myklebust" <trondmy@hammerspace.com>, anna@kernel.org,
        linux-nfs@vger.kernel.org
Subject: Re: [PATCH 0/2] NFS: limit use of ACCESS cache for negative responses
In-reply-to: <9279E15C-0A9E-4486-BE45-5DA5DF40675D@redhat.com>
References: <165110909570.7595.8578730126480600782.stgit@noble.brown>,
 <165274590805.17247.12823419181284113076@noble.neil.brown.name>,
 <72f091ceaaf15069834eb200c04f0630eca7eaef.camel@hammerspace.com>,
 <165274805538.17247.18045261877097040122@noble.neil.brown.name>,
 <acdd578d2bb4551e45570c506d0948647d964f66.camel@hammerspace.com>,
 <165274950799.17247.7605561502483278140@noble.neil.brown.name>,
 <3ec50603479c7ee60cfa269aa06ae151e3ebc447.camel@hammerspace.com>,
 <165275056203.17247.1826100963816464474@noble.neil.brown.name>,
 <d6c351439c71d95f761c89533919850c91975639.camel@hammerspace.com>,
 <D788BD7B-029F-4A4C-A377-81B117BD4CD2@redhat.com>,
 <a56ca216aef75f419d8a13dd6c7719ef15bbcaab.camel@hammerspace.com>,
 <54685EB8-7E6D-4EC4-8A9E-2BF55F41DABA@redhat.com>,
 <f5a2163d11f73e24c2106d43e72d0400d5a282b6.camel@hammerspace.com>,
 <FA952BF7-1638-4BD1-8DA9-683078CFDE8F@redhat.com>,
 <361256cf42393e2af9691b40bd51594ce078f968.camel@hammerspace.com>,
 <9279E15C-0A9E-4486-BE45-5DA5DF40675D@redhat.com>
Date:   Tue, 20 Sep 2022 08:38:12 +1000
Message-id: <166362709287.9160.2951057161316110877@noble.neil.brown.name>
Precedence: bulk

On Tue, 20 Sep 2022, Benjamin Coddington wrote:
> On 26 Aug 2022, at 20:52, Trond Myklebust wrote:
> 
> > Can we please try to solve the real problem first? The real problem is
> > not that user permissions change every hour on the server.
> >
> > POSIX normally only expects changes to happen to your group membership
> > when you log in. The problem here is that the NFS server is updating
> > its rules concerning your group membership at some random time after
> > your log in on the NFS client.
> >
> > So how about if we just do our best to approximate the POSIX rules, and
> > promise to revalidate your cached file access permissions at least once
> > after you log in? Then we can let the NFS server do whatever the hell
> > it wants to do after that.
> > IOW: If the sysadmin changes the group membership for the user, then
> > the user can remedy the problem by logging out and then logging back in
> > again, just like they do for local filesystems.
> 
> This goes a long way toward fixing things up for us, I appreciate it, and
> hope to see it merged.  The version on your testing branch (d84b059f) can
> have my:
> 
> Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
> Tested-by: Benjamin Coddington <bcodding@redhat.com>
> 

The test in that commit can be "gamed".
I could write a tool that double-forks with the intermediate exiting
so the grandchild will be inherited by init.  Then the grandchild can
access the problematic path and force the access cache for the current
user to be refreshed.  It would optionally need to do a 'find' to be
thorough.

Is this an API we are willing to support indefinitely?  Should I write
the tool?

NeilBrown