Subject: RE: LOOKUPP and NFS4ERR_WRONGSEC

From: [email-masked]
Date: Fri, 7 Feb 2003 18:32:40 -0500

> 
> >>Not an oversight.  The assumption is that if a object in 
> the server's
> >>namespace requires a particular security mechanism for 
> access that all
> >>ancestors of that object will accept the same security mechanism.
> >>This allows a client to use a single security mechanism while
> >>traversing the namespace to that node.  It also avoids the problem
> >>that you thought might exist.
> >>
> >
> >What you are effectively saying is any v4 compliant server 
> implementation
> >MUST require a nested export to be more restrictive than its 
> parent exports.
> >
> 
> 
> Well it is going to hard to make that a MUST since customers today 
> expect to attach arbitrary
> restrictions to any point of their exported namespace.
> 

I think SECINFO as it stands now requires the parent export and the child
export to share at least one common flavor. Otherwise, even going downward
using LOOKUP would not be possible. For example, suppose the parent export
supports auth_unix and child supports krb5,

PUTFH fh; LOOKUP "child_export" --> [auth_unix]
					  <-- NFS4ERR_WRONGSEC (from LOOKUP)
PUTFH fh; SECINFO "child_export" --> [krb5i as required by SECINFO]
					  <-- "krb5"
PUTFH fh; LOOKUP "child_export" --> [krb5]
	   <-- NFS4ERR_WRONGSEC (from PUTFH since the parent does not
support krb5)

> What is says that in order to prevent unauthenticated access to the 
> contents of directories,
> customers will have to export nested directories with equal 
> or greater 
> restrictions.
> 
> >
> >IMHO, the protocol should not place a limit on the way 
> security policy is
> >administered, although I can see the assumption makes sense 
> most of the
> >time.
> >
> 
> I think it is an oversight and agree with Peng.
> 
> What NFSv4.0 needed was a variant of SECINFO that took just  
> the current 
> file handle as an
> (implied) argument and not the component name. This way, to 
> do LOOKUPP that
> crossed security flavors, you would have had:
> 
> 1.    PUTFH ; LOOKUPP -->
>             <-- fh (no wrongsec error, even if the security is wrong)
> 
> 2.    PUTFH fh ; READDIR -->
> 
>         <-- NFS4ERR_WRONGSEC  (return it on the READDIR operation)
> 
> 3.    PUTFH fh ; SECINFO_CURFH -->
> 
>     <-- { rpcsec_gss, krb5, auth }
> 
> Regardless, we should not modify the NFSv4.0 specification to 
> address this.
> IESG has approved the spec as is, and it took us too long to 
> get there.
> 
> In minor revision of v4, we should address this.
> 
>     -mre
> 
>

---

From: Mike Eisler <[email-masked]>
Date: Fri, 07 Feb 2003 15:45:01 -0800

>export to share at least one common flavor. Otherwise, even going downward

That's going to really disappoint customers. But of course, I don't 
agree with that
interpretation.

>PUTFH fh; SECINFO "child_export" --> [krb5i as required by SECINFO]

The client can use whatever flavor it wants in SECINFO

>	   <-- NFS4ERR_WRONGSEC (from PUTFH since the parent does not
No, the server has to honor the request. The use of a putfh with wrong
security doesn't require enforcement, since putfh doesn't involve any 
access.

The rule is ifSECINFO for { fh, name} returns flavor X, then
a LOOKUP { fh, name} using flavor X MUST be accepted by ther server.

    -mre