V3 ACCESS call fails after server reboot

V3 ACCESS call fails after server reboot

[Frank van Maarseveen]

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

Re: V3 ACCESS call fails after server reboot

[J. Bruce Fields]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: V3 ACCESS call fails after server reboot

[Frank van Maarseveen]

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