Re: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME

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

> (and I may know more later, so this is subject
> to change)

  2.6.3.1.1.  Put Filehandle Operation + SAVEFH

   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.

There's a problem. E.g.

      PUTFH, SAVEFH, READ

As stated above, PUTFH could not return NFS4ERR_WRONGSEC.

So I am proposing that it say:

2.6.3.1.1.  Put Filehandle Operation + SAVEFH

   The client is saving a filehandle for a future RESTOREFH.
   SAVEFH MUST NOT return NFS4ERR_WRONGSEC. To determine
   whether put filehandle
   operation returns NFS4ERR_WRONGSEC or not, the server
   implementation pretends SAVEFH is not in the series of operations
   and determines which of the situations described in the
   other subsections of 2.6.3.1 apply.

On Thu, April 17, 2008 1:01 pm, Mike Eisler wrote:
> Ah, now I see why LINK and RENAME have to return NFS4ERR_WRONGSEC.
>
> PUTFH followed by SAVEFH cannot return NFS4ERR_WRONGSEC.
> 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
>


-- 
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