[PATCH 0/5] Dynamic Pseudo Root

[J. Bruce Fields]

On Tue, Feb 19, 2008 at 12:55:10PM -0800, Frank Filz wrote:
> On Tue, 2008-02-19 at 15:07 -0500, Trond Myklebust wrote:
> > One way of reconciling this with the pseudo-fs approach would be to
> > allow READDIR to succeed for the AUTH_SYS case too, but to return
> > NFS4ERR_WRONGSEC if the client attempts to retrieve any attributes or
> > filehandles for those names.
> 
> One problem with that is should this special case be any different than
> another case:
> 
> /export	*(sec=krb5)
> /export/f/foo foo_client(sec=sys:krb5)
> 
> Now foo_client has to be able to lookup f in /export to be able to get
> to the private export foo. This suggests that it only makes sense for
> pseudo root to be exported with at least read access to the most
> permissive security flavors used across the system.

It would be fine with me to just require that--I'd always assumed
configurations like the above were geeky corner cases that no one would
actually care about--but Trond seems to have been stating the opposite.

Assuming Trond is correct and that we need to support such
configurations, some choices are:

	1. Require clients to negotiate the security flavors they need
	   along the way.  This is the only approach that's been
	   discussed by the working group as far as I can tell.
	2. Show clients a completely different directory (with a
	   different filehandle) with just the paths they need.
	3. Show clients the same directory, with the same filehandle, but
	   only return the paths they need, and pretend others don't
	   exist.
	4. Something like Trond's suggestion above--make all the
	   directories along the way readable, but return no real
	   attributes for any of the other entries.

Numbers 2 and 3 return different results to the client depending on
flavor (to lookup/getfh and readdir, respectively), in situations where
number 1 would return wrongsec.  Are we sure that couldn't screw up
client lookup/directory caches in some situations?

--b.