Subject: [nfsv4] Crossing mount points without a mount protocol

From: Steven Huntington <[email-masked]>
Date: Thu, 4 Dec 2003 08:37:06 -0800

Hi all, I had a question about Pseudo NameSpace in a multi-FS environment.

Consider the following in an "exports" file, indicating what a client can
mount on my server (including descendants of that object):

/a/b/c

And suppose there is an FS addressed at "/a/b/c/d" which is INACCESSIBLE to
the client, and "/a/b/c/d/e" which is accessible.

In version  3, a client could issue a mount command to /a/b/c and
/a/b/c/d/e and could use the resultant filehandles to access the FS's which
were appropriate.

In version 4, the client must LOOKUP thru "d" to get to "e", which will
fail with EACCESS.

We would prefer not to change the name space to "virtualize" the path to
the filesystem at "e" (i.e. set up a name space at /mnt/c and another at
/mnt/e) as our customers would have to change their local exports files
depending upon whether they run v3 or v4 (client has an established
knowledge of the existing path to FS "e").  Adding a second export entry to
indicate /a/b/c/d/e is also not preferable, same reason.

Any thoughts on how the v4 mount-emulation idea is supposed to work with
POSIX in a situation like this one?  Our NFSS is generally just a traffic
director and does not necessarily know where filesystems reside (we were
counting on the mount protocol in v3).

Cheers,

Steve Huntington, IBM San Jose

Phone:            (408) 256-1948 (T/L 276-1948)
Fax                   (408) 256-2500
Office:              San Jose 50-C398
Internet:          [email-masked]
Lotus Notes: Steven Huntington/San Jose/IBM@IBMUS

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 4 Dec 2003 11:48:21 -0800 (PST)

Steve,

The pseudo-fs is supposed to address this with you creating a mock
entry for 'd'.

When your server constructs the FS labled "/a/b/c/d", you are tracking
something to know you have a different FS.  At that point, you need
to construct a pseudo-fs entry for that FS if it can be inaccessible
from any client.  Ditto for the one on "e".

Also, consider:

/a/b      -rw
/a/b/c    -rw=foo:bar
/a/b/c/d  -rw

The only hosts allowed to access "/a/b/c" are foo and bar, so they
see the real fs. But all other hosts need a pseudo fs entry to access
as they traverse down to /a/b/c/d.

You can mix this up even more with per security style host lists.

Tom

-- 
Tom Haynes, ex-cfb
[email-masked]

---

From: Brent Callaghan <[email-masked]>
Date: Thu, 04 Dec 2003 15:19:34 -0800

The pseudo-fs should certainly handle the case where a
segment of the path is not exported, or not mountable
by the client.

There is one case though where the NFSv4 semantics are still
not quite like that of the mount protocol.  If the
file permissions or an ACL are set on some directory in the path
that prevents lookup access to the client, then even
the pseudo-fs won't be able to kick in and save the day.
So NFSv4 server admins will just have to be careful
to set path directory permissions appropriately when exporting
subdirectories.

This isn't a problem for a v2 or v3 client getting access
via the mount protocol because the mountd, usually running
as superuser, will happily lookup any path - ignoring permissions.
Some of our customers saw that as a security problem, so in our
Solaris implementation of mountd we added a "nosub" option that
prevents mounting of sub directories.

	Brent