Tested on 2.6.22.10 and 2.6.23.9, client and server running same version.
export options: rw,sync,no_root_squash,no_subtree_check,mp
After a substantial amount of time (days) but also after a server
reboot a process loses access to its current working directory when
access to a parent directory two (or more) levels up has been revoked:
$ cd /mnt
$ mkdir -p a/b/c
$ cd a/b/c
$ chmod 0 ../..
$ ls -a
. ..
$
(wait a loong time or reboot server)
$ ls -a
ls: .: Permission denied
Network traffic capture showed a V3 ACCESS call for above "." failing
on the server after the reboot with NFS3ERR_ACCES. It succeeded before.
I have the impression the server is internally rechecking the entire
path when its caches have been flushed. This behavior is problematic
for daemons which change uid, for example.
Note on a different (client) issue: Trying the above with the direct
parent (i.e. chmod 0 ..) fails with ESTALE due to lookup of "c" in "b"
to which access has been revoked (no reboot needed):
$ mkdir -p a/b/c
$ cd a/b/c
$ chmod 0 ..
$ ls -a
ls: .: Stale NFS file handle
$ chmod 755 ..
$ ls -a
. ..
$
--
Frank
On Mon, Dec 10, 2007 at 06:20:04PM +0100, Frank van Maarseveen wrote:
> Tested on 2.6.22.10 and 2.6.23.9, client and server running same version.
> export options: rw,sync,no_root_squash,no_subtree_check,mp
>
> After a substantial amount of time (days) but also after a server
> reboot a process loses access to its current working directory when
> access to a parent directory two (or more) levels up has been revoked:
>
> $ cd /mnt
> $ mkdir -p a/b/c
> $ cd a/b/c
> $ chmod 0 ../..
> $ ls -a
> . ..
> $
> (wait a loong time or reboot server)
> $ ls -a
> ls: .: Permission denied
>
> Network traffic capture showed a V3 ACCESS call for above "." failing
> on the server after the reboot with NFS3ERR_ACCES. It succeeded before.
>
> I have the impression the server is internally rechecking the entire
> path when its caches have been flushed. This behavior is problematic
> for daemons which change uid, for example.
What are your export options? (Do you have nosubtreecheck turned on?)
--b.
> Note on a different (client) issue: Trying the above with the direct
> parent (i.e. chmod 0 ..) fails with ESTALE due to lookup of "c" in "b"
> to which access has been revoked (no reboot needed):
>
> $ mkdir -p a/b/c
> $ cd a/b/c
> $ chmod 0 ..
> $ ls -a
> ls: .: Stale NFS file handle
> $ chmod 755 ..
> $ ls -a
> . ..
> $
>
> --
> Frank
> -
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Dec 10, 2007 at 12:41:17PM -0500, J. Bruce Fields wrote:
> On Mon, Dec 10, 2007 at 06:20:04PM +0100, Frank van Maarseveen wrote:
> > Tested on 2.6.22.10 and 2.6.23.9, client and server running same version.
> > export options: rw,sync,no_root_squash,no_subtree_check,mp
> >
> > After a substantial amount of time (days) but also after a server
> > reboot a process loses access to its current working directory when
> > access to a parent directory two (or more) levels up has been revoked:
> >
> > $ cd /mnt
> > $ mkdir -p a/b/c
> > $ cd a/b/c
> > $ chmod 0 ../..
> > $ ls -a
> > . ..
> > $
> > (wait a loong time or reboot server)
> > $ ls -a
> > ls: .: Permission denied
> >
> > Network traffic capture showed a V3 ACCESS call for above "." failing
> > on the server after the reboot with NFS3ERR_ACCES. It succeeded before.
> >
> > I have the impression the server is internally rechecking the entire
> > path when its caches have been flushed. This behavior is problematic
> > for daemons which change uid, for example.
>
> What are your export options? (Do you have nosubtreecheck turned on?)
yes, see above export options.
--
Frank