On Tue, 2022-09-20 at 08:38 +1000, NeilBrown wrote: > 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. Sure... If two tasks share the same cred, one can do deliberately crazy stuff to break performance of the other. Is that news? -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
