Subject: READDDIR and NFS4ERR_WRONGSEC

From: Carl Burnett <[email-masked]>
Date: Wed, 20 Nov 2002 15:44:36 -0600

NFS4ERR_WRONGSEC is not listed as a possible error return on READDIR. 
Shouldn't it be?

If so, and if the client is requesting attributes, and an entry represents 
a security policy boundary that the client does not meet; then

if the client is allowing fattr4_rdattr_error, should the server return 
the fattr4_rdattr_error attribute, or NFS4ERR_WRONGSEC? 
fattr4_rdattr_error seems friendlier.

if the client is NOT allowing fattr4_rdattr_error, then it seems 
NFS4ERR_WRONGSEC needs to be returned.

Carl

Carl Burnett
AIX Kernel Architecture - Distributed File Systems
(512) 838-8498, TL 678-8498
(please reply to [email-masked])

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 20 Nov 2002 19:51:55 -0600

> NFS4ERR_WRONGSEC needs to be returned.

There is an issue with all of this that the current specification was
not updated to reflect.  If the server is allowed to return
NFS4ERR_WRONGSEC for an object within the directory (not the directory
itself) the client has no way of knowing what object was the one that
failed and will actually fall into a infinite loop of recovery from
the WRONGSEC error and reissuing the READDIR.  The reason for this is
that the WRONGSEC error will be associated with the current filehandle
used by the READDIR.  For example...

The simple scenario would be (READDIR is done without fattr4_rdattr_error):
	READDIR(cfh) 	->
			<-	[server returns NFS4ERR_WRONGSEC for entry]
	SECINFO(parent_fh, name) ->
			<-	[list of security mechanisms]
(retrans)READDIR(cfh) 	->
			<-	[server returns NFS4ERR_WRONGSEC for entry]
	...

Clearly this can not work.  Therefore, the server must have some
flexbility when it comes to the NFS4ERR_WRONGSEC condition.

There is a statement in the READDIR operation's description that does
not allow for flexibility:

			"Obviously, the client must request the
     fattr4_rdattr_error attribute for this method to work properly. If
     the client does not request the attribute, the server has no choice
     but to return failure for the entire READDIR operation."

But if the server does return the WRONGSEC error the client loops.

First, it should be strongly suggested that client's request
fattr4_rdattr_error to avoid this issue.  Second, in the Solaris
server, in the instance where the client has not requested
fattr4_rdattr_error, we have chosen to return only the name and cookie
for the entry failing with WRONGSEC.

This allows the client to receive a response to the READDIR that is
somewhat useful while not throwing it into a loop.

As a reminder the operations that may return WRONGSEC are:
LINK, LOOKUP, OPEN, PUTFH, PUTPUBFH, PUTROOTFH, RENAME, RESTOREFH

-- 
Spencer