Subject: Re: name space and exports

From: Naidu Bollineni <[email-masked]>
Date: Wed, 11 Aug 1999 17:31:58 -0700 (PDT)

In an effort to bridge the gap of unexported file systems within exported ones,

consider this:

/p exported.
/p/q unexported which has the contents r, s.
/p/q/r exported to clients A, and B, but not for C.

Should the server make a distinction of showing visible contents of q(just r)
to clients A & B, but nothing to C ?

My guess is, it should still show p/q/r to C because it is part of seeing all
export points( like showmount -e gives today).

Naidu.

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 18 Aug 1999 14:59:24 -0700

> export points( like showmount -e gives today).

Brent has previously responded to this question in a way that 
leaves the exposure of /p/q/r in your example to a policy decision
to be made at the server.  I am not sure this is entirely possible.

The scenario that is a little more interesting is one where the 
security mechanism is to change at these export points.  So lets extend 
your example in the following way.

/p exported. (with LIPKEY and KerberosV5)
/p/q unexported which has the contents r, s.
/p/q/r exported to clients A, and B, but not for C. (with LIPKEY only)

With this configuration, the client initiates access to the server
with Kerberos and executes the appropriate LOOKUPs to get to /p/q
and it then does a READDIR to see the contents of /p/q.  At this
point, how does the server determine if the client has the ability
to use LIPKEY for the appropriate access?  It can not.  Therefore,
/p/q/r must be made visible to the client so that it can attempt
a LOOKUP of /p/q/r and receive the appropriate error from the server
so it can progress to use the SECINFO procedure, etc.

In this example, the server must make the name space available
even in the instance that the client or user may not have eventual 
access to the exported file tree.

Spencer