Re: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME

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

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