Subject: Re: [nfsv4] [PATCH 0/5] Dynamic Pseudo Root

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 19 Feb 2008 14:58:16 -0500

On Tue, Feb 19, 2008 at 02:37:05PM -0500, Trond Myklebust wrote:
> 
> On Tue, 2008-02-19 at 14:09 -0500, J. Bruce Fields wrote:
> 
> > I lost you with the "per-_user_" thing.  Could you give an example?
> > 
> > Are you expecting that something like
> > 
> > 	/foo/bar        client1(sec=krb5)
> > 	/foo/bar/baz    client1(sec=sys:krb5)
> > 
> > would result in client1 being allowed to do a krb5 nfsv4 readdir on
> > /foo/bar and get a directory with just "baz"?
> 
> You mean an AUTH_SYS readdir, right?

Whoops, yes.

> Yes, that's the case I'm thinking of.
> 
> > I would have expected such a readdir to just get wrongsec.
> 
> Why? As far as the auth_sys user is concerned, he is just walking
> through a pseudo-fs in order to access the directory 'baz'. The
> equivalent in NFSv3-speak would be to do
> 
>         showmount -e server
>         mount server:/foo/bar/baz /mnt
> 
> which is run-of-the-mill stuff for autofs.

If a parent is exported with access that the child isn't, there's a
tradeoff:

	- If you allow just the limited access required to get to the
	  child, then you lose the ability of the automatic security
	  negotiation to negotiate access to the parent, since the
	  client may never get a wrongsec error.

	- If you shut off access completely, then you end up permitting
	  access only to clients that are able to negotiate the access
	  required to traverse the parent (unless the client talks to
	  mountd or guesses a filehandle).

Yeah, the first option seems more useful overall.

But have you looked, e.g., at 2.6.3.1. "put Filehandle Operation +
LOOKUP" of draft 19?  Here and elsewhere the working group seems to be
assume that security policies always apply directory-wide.

--b.
_______________________________________________
nfsv4 mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/nfsv4

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 19 Feb 2008 15:07:16 -0500

> assume that security policies always apply directory-wide.

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.

Cheers
  Trond

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 19 Feb 2008 15:21:39 -0500

On Tue, Feb 19, 2008 at 03:07:16PM -0500, Trond Myklebust wrote:
> allow READDIR to succeed for the AUTH_SYS case too,

Where by "succeed" you mean return all entries, even those not needed to
access child exports?

> but to return NFS4ERR_WRONGSEC if the client attempts to retrieve any
> attributes or filehandles for those names.

So they could traverse to the child filesystem but still likely get a
wrongsec error fairly quickly if they mount the parent.  OK, maybe.

--b.

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 19 Feb 2008 15:57:58 -0500

> Where by "succeed" you mean return all entries, even those not needed to

Return all _names_ allowed by the most permissive export option (but
return WRONGSEC if the client attempts to retrieve more than just the
name).

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 19 Feb 2008 16:18:05 -0500

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