Subject: RE: LOOKUPP and NFS4ERR_WRONGSEC

From: [email-masked]
Date: Fri, 7 Feb 2003 17:15:05 -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.
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.

Peng

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 7 Feb 2003 16:21:36 -0600

> administered, although I can see the assumption makes sense most of the

The protocol implies the requirement via the construction of the
SECINFO operation as you have pointed out.  So I guess it would be an
implicit MUST.  However, the server implementation is apply its
security policy however it wants.  There are no policy statements like
this in the protocol specification.  The only limiting factor will be
how useful a particular policy will be based on the available
protocol.

With respect to this area, I have not heard of any particular
requirements necessitating a change.

-- 
Spencer

---

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

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

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.

>administered, although I can see the assumption makes sense most of the

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