Re: [nfsv4] NFS4ERR_WRONGSEC inconsistency - LINK and RENAME

[Trond Myklebust <[e-mail]>]

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.

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

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