Re: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME

["Mike Eisler" <[e-mail]>]

On Thu, April 17, 2008 2:18 pm, Trond Myklebust wrote:
>
> On Thu, 2008-04-17 at 13:01 -0700, Mike Eisler wrote:
>> Ah, now I see why LINK and RENAME have to return NFS4ERR_WRONGSEC.
>>
>> PUTFH followed by SAVEFH cannot return NFS4ERR_WRONGSEC.
>
> I agree that this makes it consistent. You've just restated Dave's "1N
> 2N" case.
>
> I just don't see a justification for why we need to defer the WRONGSEC
> from PUTFH+SAVEFH to the RESTOREFH case.

I think though after reading the section entitled:
"Put Filehandle Operation + LOOKUP (or OPEN by Name)"
I understand the reason why PUTFH+SAVEFH cannot return
NFS4ERR_WRONGSEC. In fact the whole section entitled
"SECINFO and SECINFO_NO_NAME" makes it clear that there
are times PUTFH can return NFS4ERR_WRONGSEC. By disallowing
a PUTFH followed by SAVEFH from returning NFS4ERR_WRONGSEC, and
allowing RESTOREFH (under some conditions, same as
PUTFH) to return NFS4ERR_WRONGSEC we potentially avoid an
unnecessary NFS4ERR_WRONGSEC.

Going back to "Put Filehandle Operation + LOOKUP (or OPEN by Name)"

     b)  sec_policy_child ^ sec_policy_parent != {} (^ for intersection,
      {} for the empty set).  This means that the security tuples
      specified on the security policy of a child directory always has a
      non empty intersection with that of the parent.

  [...]

   For a server to support approach (b) (when client chooses a flavor
   that is not a member of sec_policy_parent) and (c), the put
   filehandle operation must NOT return NFS4ERR_WRONGSEC when there is a
   security tuple mismatch.  Instead, it should be returned from the
   LOOKUP (or OPEN by component name) that follows.

Suppose:

- we have these security policies on the server

       /xyz sec=sys
       /xyz/abc sec=krb5

- the fh of "xyz" is 0x123.

- the client sends this COMPOUND using krb5 creds:

   SEQUENCE, PUTFH 0x123, SAVEFH, RESTOREFH, LOOKUP "abc", GETFH

Let's say the model is (not what the spec says)
 PUTFH can return NFS4ERR_WRONGSEC if followed immediately by
 SAVEFH, and RESTOREFH can never return NFS4ERR_WRONGSEC.

PUTFH returns NFS4ERR_WRONGSEC, so the
client would issue SECINFO_NO_NAME with AUTH_SYS creds, and then
sends:

   SEQUENCE, PUTFH 0x123, SAVEFH, RESTOREFH, LOOKUP "abc", GETFH

We then get NFS4ERR_WRONGSEC on the LOOKUP, send SECINFO to find
"abc"'s policy, and then send another COMPOUND to get "abc"'s fh.

Let's say we follow the model in the spec. Again this COMPOUND
is issued with krb5 creds:

   SEQUENCE, PUTFH 0x123, SAVEFH, RESTOREFH, LOOKUP "abc", GETFH

just returns the file handle.



>
> Trond
>
>> LINK and RENAME don't require a RESTOREFH. If there is a strict
>> security policy on the saved fh used for LINK and RENAME, then without
>> NFS4ERR_WRONGSEC, that policy could be circumvented.
>>
>> So, knowing what I know now (and I may know more later, so this is
>> subject
>> to change), my new plan is:
>>
>>  Make the errors chapter synchronized with the SECINFO section:
>>  add LINK and RENAME as valid operations that can return
>>  NFS4ERR_WRONGSEC.
>>
>> On Thu, April 17, 2008 12:31 pm, Mike Eisler wrote:
>> > I was in the process of making the edits to remove RESTOREFH from
>> > the list of operations that can return NFS4ERR_WRONGSEC and came
>> > across this:
>> >
>> >
>> >   <section anchor="using_secinfo" title="Using NFS4ERR_WRONGSEC,
>> SECINFO,
>> > and SE
>> > CINFO_NO_NAME">
>> >   <t>
>> >    This section explains of the mechanics of NFSv4.1 security
>> negotiation.
>> >    The term "put filehandle operation" refers to
>> >    PUTROOTFH, PUTPUBFH, PUTFH, and RESTOREFH.
>> >   </t>
>> >
>> >    <section anchor="PUTFH + SAVEFH"
>> >     title="Put Filehandle Operation + SAVEFH">
>> >    <t>
>> >     The client is saving a filehandle for a future RESTOREFH. The
>> >     server MUST NOT return NFS4ERR_WRONGSEC to either the put
>> filehandle
>> >     operation or SAVEFH.
>> >    </t>
>> >    </section> <!-- Put Filehandle Operation + SAVEFH -->
>> >
>> > ----------
>> >
>> > There's a reason, which I do not recall, why a put filehandle op
>> > followed by SAVEFH is not allowed to return NFS4ERR_WRONGSEC.
>> >
>> > But because, e.g. PUTFH, SAVEFH cannot return _WRONGSEC, this
>> > means RESTOREFH has to return WRONGSEC.
>> >
>> >
>> > Now we could state that PUTFH, SAVEFH can return NFS4ERR_WRONGSEC,
>> > and that seems like it is OK. But then so did eliminating WRONGSEC
>> > from the list of errors RESTOREFH can return.
>> > But I have no time to figure why the spec disallows WRONGSEC on the
>> > PUTFH, SAVEFH case.
>> >
>> > So I intend to make SECINFO synchronized with the errors chapter:
>> > remove LINK and RENAME as valid operations that can return
>> > NFS4ERR_WRONGSEC.
>> >
>> > to the spec (i.e. producing an RFC that is broken).
>> > On Sun, April 13, 2008 1:54 pm, Noveck, Dave wrote:
>> >>> > So I think you have two questions:
>> >>> >
>> >>> > 1) Can security policies be on name-pattern-defined classes of
>> >> objects?
>> >>> >
>> >>> > 2) Is the saved fh protected in the same way as current fh?
>> >>> >
>> >>> > So my take is:
>> >>> >
>> >>> > 1Y, 2Y: CREATE, LINK, RENAME
>> >>>
>> >>> I think it is:
>> >>>
>> >>> 1Y, 2Y: REMOVE
>> >>>
>> >>> Why isn't REMOVE among the list? The target could have a policy.
>> >>
>> >> My intention was that REMOVE was implicitly included in all the
>> options,
>> >> just as LOOKUP is.
>> >>
>> >>> Why is CREATE on the list? If the object doesn't
>> >>> exist, it has no policy. If it does exist, then
>> >>> NFS4ERR_EXIST is what must be returned.
>> >>
>> >> Under 1Y, objects can implicitly have policies based on their names.
>> >> With the example of "*.secret" requiring kerberos, AUTH_SYS creation
>> of
>> >> "big.secret" would return WRONGSEC.
>> >>
>> >>> Why are LINK and RENAME on the list? The saved
>> >>> fh is protected.
>> >>
>> >>> LINK is linking one of the two filehandles; we've
>> >>> already checked their policies. Note that if the
>> >>> target name exists, we return NFS4ERR_EXIST. This
>> >>> is the same as CREATE.
>> >>
>> >> Here I was thinking of a name-based policy where the link matched the
>> >> link pattern.
>> >>
>> >>> RENAME: security policies should not be protecting
>> >>> the rename of the policied object. SECINFO is not
>> >>> that smart.
>> >>
>> >> RENAME identifies an existing object by name.  If the caller would
>> get
>> >> WRONGSEC doing a LOOKUP of that object, he certainly should get one
>> >> renaming it.
>> >>
>> >>> > 1Y, 2N: CREATE, LINK, RENAME, RESTOREFH
>> >>
>> >>> I think it should be:
>> >>
>> >>> 1Y, 2N: REMOVE, LINK, RENAME, RESTOREFH
>> >>
>> >>> for the same reasons as the previous 1Y, 2Y case.
>> >>
>> >> OK.
>> >>
>> >>> > 1N, 2Y: none of the above
>> >>
>> >>> Dave noted this should have had RENAME. I'm not
>> >>> seeing it. A RENAME amounts to adding a directory
>> >>> entry and deleting a directory entry. If REMOVE
>> >>> and CREATE are not on the list, why should RENAME
>> >>> be on the list?
>> >>
>> >> REMOVE was intended to be implicitly on the list as discussed above.
>> >>
>> >> The difference between CREATE and RENAME is similar to that between
>> >> CREATE and OPEN.  RENAME works on an existing object which may have
>> >> previously acquired a policy.
>> >>
>> >>> > So I think it is:
>> >>
>> >>> > 1N, 2Y: none of the above
>> >>
>> >> I think it would be RENAME and REMOVE.
>> >>
>> >>> > 1N, 2N: LINK, RENAME, RESTOREFH
>> >>
>> >>> I agree.
>> >>
>> >>> So while eliminating RESTOREFH from the list of
>> >>> operations that can return NFS4ERR_WRONGSEC is
>> >>> going to create a lot editing work for me, I agree
>> >>> that 1N, 2Y is the easiest case and the sanest way
>> >>> to deal draft-21's current inconsistency.
>> >>
>> >> I agree.
>> >>
>> >> -----Original Message-----
>> >> From: Mike Eisler [mailto:[e-mail]]
>> >> Sent: Sunday, April 13, 2008 3:55 PM
>> >> To: [e-mail]
>> >> Subject: Re: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME
>> >>
>> >>> From: Noveck, Dave
>> >>> Sent: Sunday, April 13, 2008 9:09 AM
>> >>> To: 'Trond Myklebust'; Mike Eisler
>> >>> Cc: [e-mail]
>> >>> Subject: RE: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and
>> RENAME
>> >>
>> >>
>> >>>> Also, just out of curiosity, why do we have RESTOREFH in the above
>> >>>> two
>> >>>
>> >>>> lists? Aren't you pretty much guaranteed to get a WRONGSEC error on
>> >>>> the filehandle before you get round to the SAVEFH?
>> >>>
>> >>> I think this may relate to the issue of LINK and RENAME.  If you
>> >>> create an object and continue to use it in the COMPOUND, you could
>> >>> conceive, since it is not atomic, that between two ops the server
>> >>> changes his security policy for the object in question (if you can
>> >>> ever get WRONGSEC subsequently, it has to change some time, so it
>> >>> might be before the COMPOUND is done), but the protocol has decided,
>> >>> in order to simplify client implementations, to avoid the possiblity
>> >>> of getting WRONGSEC for the current fh.  At any time that for the
>> >>> current fh, you are guaranteed not to get the error on a current fh
>> >>> once vetted when established.  You could apply the same to the saved
>> >>> fh, but you don't have to.  Not protecting the saved fh in this way
>> >>> would only mean that you had to check the error at RESTOREFH and
>> >>> anywhere that the saved fh was actually used (only LINK and RENAME,
>> I
>> >>> think)
>> >>
>> >> Makes sense.
>> >>
>> >>> So I think you have two questions:
>> >>>
>> >>> 1) Can security policies be on name-pattern-defined classes of
>> >> objects?
>> >>>
>> >>> 2) Is the saved fh protected in the same way as current fh?
>> >>>
>> >>> So my take is:
>> >>>
>> >>> 1Y, 2Y: CREATE, LINK, RENAME
>> >>
>> >> I think it is:
>> >>
>> >> 1Y, 2Y: REMOVE
>> >>
>> >> Why isn't REMOVE among the list? The target could have a policy.
>> >>
>> >> Why is CREATE on the list? If the object doesn't exist, it has no
>> >> policy. If it does exist, then NFS4ERR_EXIST is what must be
>> returned.
>> >>
>> >> Why are LINK and RENAME on the list? The saved fh is protected.
>> >>
>> >> LINK is linking one of the two filehandles; we've already checked
>> their
>> >> policies. Note that if the target name exists, we return
>> NFS4ERR_EXIST.
>> >> This is the same as CREATE.
>> >>
>> >> RENAME: security policies should not be protecting the rename of the
>> >> policied object. SECINFO is not that smart.
>> >>
>> >>> 1Y, 2N: CREATE, LINK, RENAME, RESTOREFH
>> >>
>> >> I think it should be:
>> >>
>> >> 1Y, 2N: REMOVE, LINK, RENAME, RESTOREFH
>> >>
>> >> for the same reasons as the previous 1Y, 2Y case.
>> >>
>> >>> 1N, 2Y: none of the above
>> >>
>> >> Dave noted this should have had RENAME. I'm not seeing it. A RENAME
>> >> amounts to adding a directory entry and deleting a directory entry.
>> If
>> >> REMOVE and CREATE are not on the list, why should RENAME be on the
>> list?
>> >>
>> >> So I think it is:
>> >>
>> >> 1N, 2Y: none of the above
>> >>
>> >>> 1N, 2N: LINK, RENAME, RESTOREFH
>> >>
>> >> I agree.
>> >>
>> >> So while eliminating RESTOREFH from the list of operations that can
>> >> return NFS4ERR_WRONGSEC is going to create a lot editing work for me,
>> I
>> >> agree that 1N, 2Y is the easiest case and the sanest way to deal
>> >> draft-21's current inconsistency.
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> nfsv4 mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/nfsv4
>> >>
>> >
>> >
>> > --
>> > Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
>> > http://blogs.netapp.com/eislers_nfs_blog/
>> >
>> >
>> >
>> > _______________________________________________
>> > nfsv4 mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/nfsv4
>> >
>>
>>
>
>


-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/



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