From: Spencer Shepler (shepler@eng.sun.com)
Date: 11/20/02-08:27:15 PM Z
Date: Wed, 20 Nov 2002 20:27:15 -0600 From: Spencer Shepler <shepler@eng.sun.com> Subject: Re: READDDIR and NFS4ERR_WRONGSEC Message-ID: <20021121022714.GE100649@dhcp-uaus08-128-197.sun.com> On Wed, Carl Burnett wrote: > 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? 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. > 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. Technically, yes, the server is violating the specification but it is better than throwing the client into an infinite loop of WRONGSEC/READDIR requests. > 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 ;-). 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
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:29 AM Z CST