Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!wuarchive!psuvax1!hydra!droms From: droms@regulus.bucknell.edu (Ralph E. Droms) Newsgroups: comp.protocols.nfs Subject: Re: Why not export /fs /fs/subdir? Message-ID: Date: 25 Jun 91 14:36:46 GMT References: <1991Jun18.040038.15141@Think.COM> <10284@star.cs.vu.nl> Sender: news@hydra.bucknell.edu Reply-To: droms@bucknell.edu Organization: Bucknell University, Lewisburg, Pa. Lines: 47 In-reply-to: sater@cs.vu.nl's message of 24 Jun 91 08:45:26 GMT In article <10284@star.cs.vu.nl> sater@cs.vu.nl (Hans van Staveren) writes: > >Have you tried this anywhere and had it give you access to >other filesystems? I'd call systems like that "broken". > >Rob T We have tried it. I can assure you that at least SunOs 4.1.1 NFS servers are broken in the sense you call it. Perhaps Rob T and I are not talking about the same situation. Suppose I have the following filesystem subtree on an NFS server S (where '*' is some arbitrary path): * / \ / \ A B and the export list on S: */A -access=A */B -access=B I can handcraft a program that issues NFS requests (through callrpc) from A to do: fh = mount("*/A"); fh = lookup(fh, ".."); fh = lookup(fh, "B"); fh = lookup(fh, "bar"); result = read(fh, buf); buf now contains the contents of "*/B/bar", although A has not mounted and S has explicitly exported "*/B" to be inaccessible to client A. This experiment was run on between a Sun 4/20 client and a Sun 3/160 client, both running SunOS 4.1 (*not* 4.1.1). The exported file system information is managed by the mount daemon and protocol. How would the NFS server learn of that information? -- - Ralph Droms Computer Science Department droms@bucknell.edu 323 Dana Engineering Bucknell University (717) 524-1145 Lewisburg, PA 17837