Subject: bumping the seqid on which errors?

From: Eric Kustarz <[email-masked]>
Date: Fri, 16 Aug 2002 14:10:20 -0700 (PDT)

A recent discussion brought up this problem with the spec.  
Currently the last paragraph in Section 8.1.5 states:

"The client MUST monotonically increment the sequence number 
for the CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and 
OPEN_DOWNGRADE operations.  This is true even in the event 
that the previous operation that used the sequence number 
received an error.  The only exception to this rule is if the 
previous operation received one of the following errors: 
NFS4ERR_STALE_CLIENTID, NFS4ERR_STALE_STATEID, 
NFS4ERR_BAD_STATEID, NFS4ERR_BAD_SEQID."

I think there are a couple more errors that need to be added 
to the list of "errors of which you do not bump the seqid":

NFS4ERR_RESOURCE
NFS4ERR_BADXDR
NFS4ERR_SERVERFAULT
NFS4ERR_NOFILEHANDLE
NFS4ERR_BADHANDLE

For NFS4ERR_RESOURCE, the resource error may be a temporary 
memory resource allocation error and actually deals with the 
incrementing of the seqid (tracking the last request of the 
client) and the server may not be able to meet the 
requirement.

The BADXDR case may happen during the attribute processing 
which is encoded after the seqid and owner.  So the current 
rules say that the server MUST increment seqid in the case 
that there is an XDR decode error.  That doesn't seem 
reasonable from an implementation perspective and isn't really 
the intent.

The same goes for SERVERFAULT.  It is another catch all error 
for the server and may point to a resource like issue that 
prevents the server from tracking the sequence id.

In the cases of NOFILEHANDLE/BADHANDLE, it doesn't seem 
reasonable to ask the server to continue processing a request 
because the client has given it a malformed request.  In fact, 
there may be a malicious client out 
there that may be able to authenticate requests to the server 
but has no access to the server's namespace.  With the current 
requirement, it would still be able to obtain server resources 
by the tracking of a seqid for an openowner for a request that 
never used a PUT*FH operation before an OPEN.

any humble opinions?

eric

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 22 Aug 2002 05:59:01 -0700

> > 
> > My humble opinion is that we should add BADXDR and RESOURCE and 
> > not the others.
>
> I agree with BADXDR and RESOURCE and am willing to give in on
> BADHANDLE and SERVERFAULT.  I would like to see NOFILEHANDLE added to
> the list for "no seqid increment".

NOFILEHANDLE is OK with me.  Unless someone else wants to weigh in on
this fascinating topic, it looks like we have consensus.