Subject: Re: name space and exports

From: Brent Callaghan <[email-masked]>
Date: Wed, 11 Aug 1999 17:35:20 -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).

Good question.  

Some argue that the MOUNT protocol already gives
away too much information through commands such as showmount -e.

For instance, if I have a secret directory called "/export/blowupcongress"
that I export to one other client, then all clients can see the name
of the directory (and perhaps figure out its significance) through
the MOUNT protocol. Even if they can't mount the directory and see 
what's inside it - you may not want the name to be visible.

On the other hand, there's a counter argument that addresses ease-of-use.
If I can see the directory but cannot get into it because of a permission
error - then I have some idea of what the problem is.  If I cannot see
the directory at all - then I may question its existence.

IMO the arguments are worth discussing in the spec - but the protocol
shouldn't mandate one or the other.  Leave it up to the implementation
to decide what's best.  For example: some implementation may include
a "visible" export option.

	Brent

---

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

> For example: some implementation may include a "visible" export option.

This can be a better idea than leaning on any one side.

And this leaves the decision(or flexibility) to the admin.

Spec can mention this, instead of the implementor to guess.

- Naidu.

---

From: Naidu Bollineni <[email-masked]>
Date: Wed, 18 Aug 1999 15:10:46 -0700 (PDT)

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

makes more sense.
Naidu.

---

From: Brent Callaghan <[email-masked]>
Date: Wed, 18 Aug 1999 15:59:21 -0700 (PDT)

Spencer Shepler writes:
> /p exported. (with LIPKEY and KerberosV5)
> /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,
> 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.

Yep, that's certainly true if the client was browsing it's
way down the directory tree with a sequence of READDIR/LOOKUP
requests.  

However, if we assume that the client "knows" the path perhaps
via a URL sent via Email, then a secret directory could be
hidden from READDIR - yet be evaluated via LOOKUP.  This is
analogous the the UNIX directory read permission vs search
permission. 

	Brent