Subject: Re: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME

From: "Mike Eisler" <[email-masked]>
Date: Thu, 17 Apr 2008 20:12:18 -0700 (PDT)

On Thu, April 17, 2008 7:59 pm, Trond Myklebust wrote:

>> 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.
>
> This just proves to show how screwed up the rules are: basically the

I think the rules are an improvement in NFSv4.0.

Client implementers have expressed in the past that they
don't want to deal with NFS4ERR_WRONGSEC on every operation.

> server is required to look ahead to see
>
>   - Am I doing PUTFH+<not SAVEFH>
>         - Yes: return NFS4ERR_WRONGSEC
>         - No: Am I doing PUTFH+SAVEFH+<some operation that depends on
>         current fh>
>                 - Yes: return NFS4ERR_WRONGSEC
>                 - No: wait for the RESTOREFH in order to return
>                 NFS4ERR_WRONGSEC
>
> Why?....

I gave an example ... one COMPOUND vs three.
Security policy flexibility in another.

If people would rather return NFS4ERR_WRONGSEC on every operation,
have restrictions on security policies, etc. then they should
have expressed that years ago, or even a few months ago.

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

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