Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!sdd.hp.com!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.wizards
Subject: Re: why can't you exportfs /dir and /dir/sub?
Keywords: export exportfs mount NFS subdirectories
Message-ID: <1991Jun18.232402.22982@Think.COM>
Date: 18 Jun 91 23:24:02 GMT
References: <1991Jun18.044122.16327@thunder.mcrcim.mcgill.edu> <1991Jun18.115643.629@prl.dec.com> <10241@star.cs.vu.nl>
Sender: news@Think.COM
Reply-To: barmar@think.com
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 30

In article <10241@star.cs.vu.nl> leendert@cs.vu.nl (Leendert van Doorn) writes:
>boyd@prl.dec.com (Boyd Roberts) writes:
>#In article <1991Jun18.044122.16327@thunder.mcrcim.mcgill.edu>, mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
>#> Well yes, that's the bug.  The question is, why couldn't they fix it?
>#I guess the bug-fix would violate the stateless protocol :-)
>Actually it wouldn't. It would only blur the functional division
>between the mount daemon and the NFS daemon. All the NFS daemon has to
>do is to enforce the restrictions set in the /etc/export file. It has
>to check every NFSPROC_LOOKUP operation on "..". 

Actually, there's more to it than that.  Consider the following situation:

/foo -access=foo
/foo/bar -access=bar

First of all, there's an ambiguity here.  Does the /foo entry mean that the
foo client has access to everything under /foo, or does the explicit
/foo/bar cause that subhierarchy to be shadowed?  If this is to be
consistent with the case where the directories are on different file
systems, I guess the second one should shadow.

Your suggestion keeps bar from getting out of /foo/bar, but it doesn't stop
foo from getting in.  To do this, the opposite restriction must also be
enforced on all NFSPROC_LOOKUP and NFSPROC_READDIR operations for which the
directory handle corresponds to /foo/bar.
-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar