felps@convex.com (Robert Felps) (06/13/91)
Why can't this be done?
EXPORTFS(8) NFS Programmer's Reference EXPORTFS(8)
WARNINGS
You cannot export a directory that is either a parent- or a
sub-directory of one that is currently exported and within
the same filesystem. It would be illegal, for example, to
export both /usr and /usr/local if both directories resided
in the same disk partition.amirosh@shakespyr.Pyramid.COM (Alex Miroshnichenko) (06/14/91)
In article <felps.676828858@convex.convex.com>, felps@convex.com (Robert Felps) writes: |> |> Why can't this be done? |> |> EXPORTFS(8) NFS Programmer's Reference EXPORTFS(8) |> |> WARNINGS |> You cannot export a directory that is either a parent- or a |> sub-directory of one that is currently exported and within |> the same filesystem. It would be illegal, for example, to |> export both /usr and /usr/local if both directories resided |> in the same disk partition. exportfs is performed on a filesystem, not on a directory tree.
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (06/18/91)
In article <159281@pyramid.pyramid.com>, amirosh@shakespyr.Pyramid.COM (Alex Miroshnichenko) writes: > In article <felps.676828858@convex.convex.com>, felps@convex.com (Robert > Felps) writes: >> Why can't this be done? >> EXPORTFS(8) NFS Programmer's Reference EXPORTFS(8) [...] >> You cannot export a directory that is either a parent- or a >> sub-directory of one that is currently exported and within the >> same filesystem. > exportfs is performed on a filesystem, not on a directory tree. Well yes, that's the bug. The question is, why couldn't they fix it? der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
boyd@prl.dec.com (Boyd Roberts) (06/18/91)
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 :-) Boyd Roberts boyd@prl.dec.com ``When the going gets wierd, the weird turn pro...'' protocol :-)
leendert@cs.vu.nl (Leendert van Doorn) (06/18/91)
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 "..". This isn't as expensive as it appears: the root-vnodes of the exported file systems should be cached with a special flag, when a lookup is performed and the current vnode has this bit set it should perform the access check. But, as said before, this would break the functional division. Leendert -- Leendert van Doorn <leendert@cs.vu.nl> Vrije Universiteit / Dept. of Maths. & Comp. Sc. +31 20 5485301 Amoeba project / De Boelelaan 1081A 1081 HV Amsterdam / The Netherlands
barmar@think.com (Barry Margolin) (06/19/91)
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