All of lore.kernel.org
 help / color / mirror / Atom feed
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
Date: Tue, 20 Sep 2022 08:38:12 +1000	[thread overview]
Message-ID: <166362709287.9160.2951057161316110877@noble.neil.brown.name> (raw)
In-Reply-To: <9279E15C-0A9E-4486-BE45-5DA5DF40675D@redhat.com>

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

  reply	other threads:[~2022-09-19 22:38 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-28  1:37 [PATCH 0/2] NFS: limit use of ACCESS cache for negative responses NeilBrown
2022-04-28  1:37 ` [PATCH 1/2] NFS: change nfs_access_get_cached() to nfs_access_check_cached() NeilBrown
2022-04-28  1:37 ` [PATCH 2/2] NFS: limit use of ACCESS cache for negative responses NeilBrown
2022-05-17  0:05 ` [PATCH 0/2] " NeilBrown
2022-05-17  0:20   ` Trond Myklebust
2022-05-17  0:40     ` NeilBrown
2022-05-17  0:55       ` Trond Myklebust
2022-05-17  1:05         ` NeilBrown
2022-05-17  1:14           ` Trond Myklebust
2022-05-17  1:22             ` NeilBrown
2022-05-17  1:36               ` Trond Myklebust
2022-08-26 14:59                 ` Benjamin Coddington
2022-08-26 15:44                   ` Trond Myklebust
2022-08-26 16:43                     ` Benjamin Coddington
2022-08-26 16:56                       ` Trond Myklebust
2022-08-26 18:27                         ` Benjamin Coddington
2022-08-27  0:52                           ` Trond Myklebust
2022-09-19 19:09                             ` Benjamin Coddington
2022-09-19 22:38                               ` NeilBrown [this message]
2022-09-20  1:18                                 ` Trond Myklebust
2022-08-26 23:39                     ` NeilBrown
2022-08-27  3:38                       ` Trond Myklebust
2022-08-28 23:32                         ` NeilBrown
2022-08-29 14:07                           ` Jeff Layton
2022-09-03  9:57                             ` NeilBrown
2022-09-03 15:49                               ` Trond Myklebust
2022-09-04 23:28                                 ` NeilBrown
2022-09-04 23:40                                   ` Trond Myklebust
2022-09-05  0:09                                     ` NeilBrown
2022-09-05  0:49                                       ` Trond Myklebust

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=166362709287.9160.2951057161316110877@noble.neil.brown.name \
    --to=neilb@suse.de \
    --cc=anna@kernel.org \
    --cc=bcodding@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@hammerspace.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.