From: Brent Callaghan (brent@eng.sun.com)
Date: 12/04/03-05:19:34 PM Z
Message-ID: <3FCFC106.9040800@eng.sun.com> From: Brent Callaghan <brent@eng.sun.com> Subject: Re: [nfsv4] Crossing mount points without a mount protocol 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 Haynes, Tom wrote: > 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 > > >>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: shunting@us.ibm.com >>Lotus Notes: Steven Huntington/San Jose/IBM@IBMUS >> >> >>_______________________________________________ >>nfsv4 mailing list >>nfsv4@ietf.org >>https://www1.ietf.org/mailman/listinfo/nfsv4 >> > > > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4
This archive was generated by hypermail 2.1.2 : 03/04/05-02:12:56 AM Z CST