Subject: [nfsv4] Readdir cookie verifier for cookie of 0

From: Rick Macklem <[email-masked]>
Date: Mon, 9 Jul 2018 12:36:55 +0000

Hi,

Ever since I first coded NFSv3 in 1994, I assumed that when the Readdir cookie
is all 0s, that the cookie verifier would be as well.
Here's the snippet from RFFC5661 (RFC1813 isn't a lot different):
   The request's cookieverf field should be set to 0 zero) when the
   request's cookie field is zero (first read of the directory).  On
   subsequent requests, the cookieverf field must match the cookieverf
   returned by the READDIR in which the cookie was acquired.  If the
   server determines that the cookieverf is no longer valid for the
   directory, the error NFS4ERR_NOT_SAME must be returned.

A packet trace for the ESXi6.7 NFSv4.1 client shows that the first time the
Readdir has a cookie of all 0s and a cookie verifier of all 0s as I had expected.
However, a subsequent Readdir has a cookie of all 0s and a cookie verifier from
a previous Readdir. Looking at the above, I can see the ambiguity caused mainly
by the "(first read of the directory)".

The FreeBSD server currently returns an error (happens to be NFS3ERR_BAD_COOKIE,
which is the wrong one, but that is obviously my bug;-).
I am think of changing the server to ignore the cookie verifier when the cookie is
all 0s.
What do others think of this? rick

---

From: Rick Macklem <[email-masked]>
Date: Mon, 9 Jul 2018 12:55:26 +0000

Just fyi, I looked and the FreeBSD server doesn't generate any error
for NFSv3 when the cookie is 0 and the cookie verifier isn't 0, it only
does it for NFSv4. (It also specifically does the NFS4ERR_BAD_COOKIE
and not NFS4ERR_NOT_SAME, although it uses NFS4ERR_NOT_SAME
for when the cookie verifier changes. I wonder if this was is some
draft of NFSv4.0 long ago?)

rick

________________________________________
From: nfsv4 <[email-masked]> on behalf of Rick Macklem <[email-masked]>
Sent: Monday, July 9, 2018 8:36:55 AM
To: [email-masked]
Cc: NAGY Andreas; Daniel Engel
Subject: [nfsv4] Readdir cookie verifier for cookie of 0

Hi,

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Tom Talpey <[email-masked]>
Date: Mon, 9 Jul 2018 09:03:55 -0400

I think the text is trying to say "MUST be ignored" instead of weakly
saying "should be zero". I don't remember there being any statement
about a reserved zero value, or how the server should handle it, so
"zero" has no special significance.

Tom.

---

From: David Noveck <[email-masked]>
Date: Mon, 9 Jul 2018 09:56:53 -0400

> saying "should be zero".

If so, it isn't trying very hard.

I do believe that is what the spec should have said.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 9 Jul 2018 15:39:41 -0500

> I do believe that is what the spec should have said.

On the other hand, "MUST be ignored" is kind of asking for someone to
implement the other side as "send some random kernel memory on the wire".

-Ben

---

From: Tom Talpey <[email-masked]>
Date: Mon, 9 Jul 2018 17:27:00 -0400

> implement the other side as "send some random kernel memory on the wire".

Sure, "MBZ" text usually reads as "SHOULD be sent as zero and MUST be
ignored on receipt". The MUST being the more important statement.

Tom.

---

From: David Noveck <[email-masked]>
Date: Mon, 9 Jul 2018 19:01:53 -0400

I don't think "SHOULD be sent as zero" would be in accord with RFC 2119.

RFC2119 says:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there

   may exist valid reasons in particular circumstances to ignore a

   particular item, but the full implications must be understood and

   carefully weighed before choosing a different course.

The problem with "SHOULD" in this case, is that not clear how the full
implications of sending anything other than zero can be understood
when there aren't any such implications, and "MUST be ignored"
basically says there are no such implications, i.e. that the sender
can send whetever it wants.

I don't see the problem that Ben sees with a straight "MUST be
ignored" but I think you could say either of the following:

should be sent by the client as zero but MUST be ignored by the server.

In this case the verifier is not used and MUST be ignored by the
server.  Although a value of zero is typically sent in this case, the
client MAY send any value it chooses.

---

From: Tom Talpey <[email-masked]>
Date: Mon, 9 Jul 2018 20:28:02 -0400

On 7/9/2018 7:01 PM, David Noveck wrote:
> implications of sending anything other than zero can be understood when 
> there aren't any such implications, and "MUST be ignored" basically says 
> there are no such implications, i.e. that the sender can send whetever 
> it wants.

Well, because the RFCs back to 1813 all said zero, I'd say SHOULD is
reasonable. But, whatever.

Tom.

> I don't see the problem that Ben sees with a straight "MUST be ignored" 
> but I think you could say either of the following:
> 
> On Mon, Jul 9, 2018 at 5:27 PM, Tom Talpey <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>                > I think the text is trying to say "MUST be ignored"
>             instead of weakly
> 
>                 saying "should be zero".
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/nfsv4>
> 
> 
> 
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 9 Jul 2018 21:30:53 -0500

> ignored" but I think you could say either of the following:

It's not a problem with the spec per se, more of a "the world will build a
better fool" sort of thing.  That is, if the spec says nothing about what
to put there, eventually, someone will implement it in a memory-unsafe
language (like C) and forget to write anything to the memory before sending
it on the wire.  And lo, a CVE for kernel information disclosure --
entirely the implementation's fault, but also eminently predictable.

> client MAY send any value it chooses.

I'd be fine with either of these, though I somewhat expect some of my
fellow IESG members to look funny at the first one and ask if a capitalized
"SHOULD" is better, just due to conditioning for seeing it that way.

-Ben

---

From: David Noveck <[email-masked]>
Date: Tue, 10 Jul 2018 06:44:48 -0400

> "SHOULD" is better, just due to conditioning for seeing it that way.

That sort of thing sometimes happens during IESG consideration.

To avoid that prospect, I would probably, if submitting an actual document
write something like:

is most appropriately sent by the client as zero but MUST be ignored by the
server.