Re: [nfsv4] 4.0 trunking

["J. Bruce Fields" <[e-mail]>]

On Thu, Sep 22, 2016 at 07:59:40AM -0400, David Noveck wrote:
> The question is what else, if anything needs to be fixed.  I had been
> thinking that the problems you were seeing indicated that the algorithm in
> section 5.8 needed correcting.  As it now appears that the Linux client had
> implemented something different than that, the correctness of the algorithm
> in section 5.8 has to be considered an open question.

It has the same problem; I could propose some language if you'd like.

> I'm not sure of the exact context here, but you have to be aware of the
> possibility that a new verifier will not be generated because a given
> request is treated as a replay.  If you are not doing a callback-changing
> SETCLIENTIDs, it is easy to fall into this case.

7530 requires a new verifier even in the case the callback information
isn't new.  ("The server treats this as a probable callback information
update and records an unconfirmed { v, x, c, k, t } and leaves the
confirmed { v, x, c, l, s } in place, such that t != s.  It does not
matter whether k equals l or not.")

If you think there's a risk anyway for some reason (bugs, or xid
wraparound, maybe?), then we could continue advising a callback-changing
SETCLIENTID here.

(The Linux client always changes the callback information on this
setclientid so my particular case isn't at issue.)

To further muddy the waters: I also found Linux knfsd isn't always
rejecting SETCLIENTID_CONFIRMs with incorrect verifiers when it should.
Even with that bug fixed, this problem is still likely thanks to the
weak verifier generation (which I'm also fixing).  So I'm still
motivated to fix the protocol.

I checked our revision history, and that Linux nfsd bug has been there
undetected from the start (13-14 years).  There's some risk to depending
on behavior that implementations have never previously depended on.

--b.