Subject: [nfsv4] question about nfs41 wrongsec processing rules

From: "Jeff A. Smith" <[email-masked]>
Date: Mon, 05 Nov 2007 11:15:34 -0600

I was reading sec. 2.6.3.1 of draft 15, "Using NFS4ERR_WRONGSEC,  
SECINFO, and SECINFO_NO_NAME", and I found a scenario that I've been  
unable to resolve
to my satisfaction using the wrongsec processing rules.  I suspect  
that I've
misinterpreted some of the section.

Here's a link to the section in draft 15:
http://www.nfsv4-editor.org/draft-15/draft-ietf-nfsv4- 
minorversion1-15.html#Security%20Error

Question:
    If a client sent a NFS41 server the compound below,
    and the current secflavor is not allowed, which op
    can the server fail w/wrongsec?

    PUTFH* + SECINFO_NO_NAME(cur_fh) + OPEN(fh)
    Note: PUTFH* is the same as the draft's
          usage of "Put Filehandle operation")

Answer: none?

section 2.6.3.1.5 states:
      "The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC
       to a put filehandle operation whenever it is immediately
       followed by SECINFO or SECINFO_NO_NAME. The NFSv4.1
       server MUST NOT return NFS4ERR_WRONGSEC from SECINFO
       or SECINFO_NO_NAME."

That seems clear enough.  I can't fail putfh+secinfo_no_name
with wrongsec, and it makes perfect sense.  The server should
provide the secinfo result so the client won't have to guess
the correct flavor.  So what about the open(cur_fh) op?

section 2.6.3.1.7 "Put filehandle operation + anything else"
      "Anything Else" includes OPEN by filehandle."
and
      "The NFSv4.1 server MUST not return NFS4ERR_WRONGSEC to
       any operation other than a put filehandle operation,
       LOOKUP, LOOKUPP, and OPEN (by component name)."

The server is allowed to return wrongsec for
OPEN(claim_null, name) but not OPEN(claim_fh, FH).
I think I understand why the distinction is made.
OPEN(name) changes the cur_fh like the other ops
mentioned, but OPEN(fh) does not.

Since the server was not allowed to fail any of the ops
in the compound with wrongsec, it just allowed a (rogue)
client to open a file using the wrong sec flavor.
This seems like a very bad thing.  I said rogue client
simply because the solaris client is not structured such
that it can build compounds like this.  Obviously, for
this to "work" the client would have needed to obtain
the FH initially using an acceptable flavor.  After that
point, the allowed flavor changed.

What about the compound below?  Which OP can the server fail
with wrongsec?  Assume the server would like to fail the
initial PUTFH* op with wrongsec.

     PUTFH* + SECINFO_NO_NAME(cur_fh) + OPEN(claim_fh) +
         READ(cur_stateid) + CLOSE(cur_stateid)

The last sentence of 2.6.3.1.7 "Put Filehandle + Anything Else"
prevents the server from failing the OPEN(FH), READ, and CLOSE
operations with WRONGSEC.  To match this rule requires that
after the PUTFH*+SECINFO match, the server keeps the PUTFH
"in play" and keeps looking for matches on the remaining ops.

I suspect this the source of my problem, and I've taken a
little too much creative license in interpreting this section.

How can the server return WRONGSEC for this compound and
adhere to the wrongsec processing rules in 2.6.3.1.*?

I have some ideas on how to tweak the section to allow
the server to fail the compounds with WRONGSEC, but before
going there, I want to make sure I'm applying the rules
correctly to the compound.  I'm also not sure I understand
the requirements being met by this section, so my actually
proposing a change at this point would be foolish.

Could someone please clarify how a server should apply
the wrongsec processing rules?  For the questions below,
assume that the PUTFH* is not using the correct sec flavor,
and the server would like to return WRONGSEC as soon as it
can.

a) Should wrongsec processing be applied to all ops or
    only at the start of the compound?
    (I think all)

b) Once a match is made, is wrongsec processing over?
    (I think no.  Keep looking for op matches.)

c) If the answer to b) is "no, keep looking", then how is
    the search restarted?  If we matched a PUTFH+SECINFO,
    do we start looking for another PUTFH or do we keep
    the initial PUTFH in play, and look for other ops which
    would cause wrongsec processing rule matches?

Jeff

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

---

From: Mike Eisler <[email-masked]>
Date: Mon, 5 Nov 2007 21:27:43 -0800 (PST)

>           usage of "Put Filehandle operation")

I agree that the literal interpretation of what is in draft-15
is "none". That obviously isn't what we want.

I'm loath to add text to the spec that allows NFS4ERR_WRONGSEC in the
final operation of:

<put filehandle op> + SECINFO* + <any op>

Client implementations that carefully construct COMPOUNDs shouldn't
have
to add NFS4ERR_WRONGSEC to its table of allowable error codes for
every file-based operation in the protocol.

Instead, I suggest we state that combinations that create
the conundrum Jeff has pointed out get NFS4ERR_UNSAFE_COMPOUND.
The server MAY return NFS4ERR_UNSAFE_COMPOUND or it the security 
tuple used is acceptable, it MAY allow <any op> to execute
successfully.

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 05 Nov 2007 23:36:52 -0600

> tuple used is acceptable, it MAY allow <any op> to execute

I am okay with this; essentially the client is strongly discouraged
from constructing COMPOUNDs of this nature and if it chooses to then
the NFS4ERR_UNSAFE_COMPOUND can be interpreted similarly to the
receipt of WRONGSEC.

Spencer

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 6 Nov 2007 06:05:30 -0500

> Client implementations that carefully construct COMPOUNDs 
> shouldn't have to add NFS4ERR_WRONGSEC to its table of 
> allowable error codes for every file-based operation in 
> the protocol.

Why not?

> the conundrum Jeff has pointed out get NFS4ERR_UNSAFE_COMPOUND.

How is adding UNSAFE_COMPOUND to the table, different from
ading WRONGSEC, except that when you get it you are likely to
be more confused.

I know that as of draft-15, the error/op table does allow this,
but right now the majority opinion is to get rid of it in all the
ops where it can't happen, given the only thing the spec says 
about UNSAFE_COMPOUND:

   o  A server MAY return NFS4ERR_UNSAFE_COMPOUND to a non-idempotent
      current filehandle change operation, if it looks at the next
      operation (in the same COMPOUND procedure) and finds it is not
      GETFH.  The server SHOULD do this if it is unable to determine in
      advance whether the total response size would exceed
      ca_maxresponsesize_cached or ca_maxresponsesize.

successfully.

Does it make sense to turn USAFE_COMPOUND into a grab-bag of different
error situations and apply it to all the ops where any of those can
occur,
or even even all ops?

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Tuesday, November 06, 2007 12:28 AM
To: [email-masked]
Subject: Re: [nfsv4] question about nfs41 wrongsec processing rules

>           usage of "Put Filehandle operation")

I agree that the literal interpretation of what is in draft-15 is
"none". That obviously isn't what we want.

Client implementations that carefully construct COMPOUNDs shouldn't have
to add NFS4ERR_WRONGSEC to its table of allowable error codes for every
file-based operation in the protocol.

Instead, I suggest we state that combinations that create the conundrum
Jeff has pointed out get NFS4ERR_UNSAFE_COMPOUND.
The server MAY return NFS4ERR_UNSAFE_COMPOUND or it the security tuple
used is acceptable, it MAY allow <any op> to execute successfully.

---

From: Mike Eisler <[email-masked]>
Date: Tue, 6 Nov 2007 03:25:39 -0800 (PST)

> > allowable error codes for every file-based operation in 

I recall this was feedback client implementors gave dating back to
before RFC3530 was published.

> ading WRONGSEC, except that when you get it you are likely to

The client that causes NFS4ERR_UNSAFE_COMPOUND to be returned is
doing something wrong. Recovery isn't possible.

Whereas, NFS4ERR_WRONGSEC doesn't indicate the client is doing 
something wrong, and the rules for NFS4ERR_WRONGSEC are intended 
to allow the client to recover).

>       ca_maxresponsesize_cached or ca_maxresponsesize.

NFS4ERR_UNSAFE_COMPOUND is arguably about a badly constructed
COMPOUND request. The "UNSAFE" might be more generalized to be "BAD".

So the text could be:

A server MAY return NFS4ERR_BAD_COMPOUND from

*  a non-idempotent current filehandle change operation, if it looks at
the next operation (in the same COMPOUND procedure) and finds it is not
GETFH. The server SHOULD do this if it is unable to determine in
advance whether the total response size would exceed
ca_maxresponsesize_cached or ca_maxresponsesize.

* any operation in a COMPOUND if it consists of a put filehandle
operation followed by SECINFO or SECINFO_NO_NAME, and an operation
after SECINFO or SECINFO_NO_NAME uses the filehandle specified in the
put filehandle operation. 

Or we could create another error code, and leave
NFS4ERR_UNSAFE_COMPOUND
as is.
> tuple