Subject: Re: READDDIR and NFS4ERR_WRONGSEC

From: Carl Burnett <[email-masked]>
Date: Wed, 20 Nov 2002 20:18:12 -0600

Thanks for the very helpful response Spencer. I couple of fallout 
questions.

1) What was the rational behind providing the client the option of getting 
the fattr4_rdattr_error attribute. It seems like suicide not to request 
it?

2) Based on the current wording in the spec (If
     the client does not request the attribute, the server has no choice
     but to return failure for the entire READDIR operation.), isn't the Solaris behavior you described violating the spec? Not that I 
disagree conceptually with the approach, but isn't it possible that a 
client will "choke" or do the wrong thing on the returned entry with no 
associated attributes? What if the server instead returned NFS4ERR_ACCESS, 
and in response, the recommend client action was to re-issue the readdir 
without requesting attributes. A client could also respond to a 
NFS4ERR_WRONGSEC the same way.

Would it be reasonable to update the spec to remove the client option to 
request fattr4_rdattr_error_attribute, and just always have the server set 
it, if it can't build the attributes for the entry. I know it, I said the 
evil update word; please go easy on the return fire ;-).

Thanks,
Carl

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

Spencer Shepler <[email-masked]>
Sent by: [email-masked]
11/20/2002 07:51 PM
Please respond to spencer.shepler

        To:     [email-masked]
        cc: 
        Subject:        Re: READDDIR and NFS4ERR_WRONGSEC

On Wed, Carl Burnett wrote:
> 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

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

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 20 Nov 2002 20:27:15 -0600

> the fattr4_rdattr_error attribute. It seems like suicide not to request 

The rationale was an extension of the GETATTR model in that the client
requests the exact set of attributes that it wants.  None are
required.  At the time, we obviously had not thought carefully enough
about the implications in the context of security policy boundaries
and the returning of WRONGSEC.

> NFS4ERR_WRONGSEC the same way.

Technically, yes, the server is violating the specification but it is
better than throwing the client into an infinite loop of
WRONGSEC/READDIR requests.

> evil update word; please go easy on the return fire ;-).

No. I don't think and update to the specification is required.  I
think we can starting building an internet draft around implementation
issues and add this particular item to the list of things that need to
be cleaned up for the first minor version.

As for specific solution, I would state that the client still have the
option to ask for the error and the server has the flexbility of
either returning the attribute unsolicited or responding in the way
the Solaris server does today.

Spencer