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@xxxxxxxxxx> > Tested-by: Benjamin Coddington <bcodding@xxxxxxxxxx> > 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
