Re: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME

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

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