[1751] in bugtraq
Re: nfs handles/lifetime
daemon@ATHENA.MIT.EDU (Yossi Gottlieb)
Wed May 10 01:04:34 1995
From: Yossi Gottlieb <yogo@math.tau.ac.il>
To: bugtraq@fc.net
Date: Wed, 10 May 1995 02:11:41 +0300 (GMT+0300)
In-Reply-To: <9505090248.AA12739@statler.CalPoly.Edu> from "Nathan Lawson" at May 8, 95 07:48:09 pm
> Now, since all access checking is done with mountd, won't an exported system
> still be available for access if you have its old filehandle even though the
> admin takes its entry out of /etc/exports? For instance, let's say A is a
> server, and B is its client. A exports /usr to B.
That's right.
> B mounts A:/usr and writes down the filehandle. A decides to stop exporting
> /usr and removes it from the exports file. Can B still access files in /usr?
Yes, B can still do so, unless the nfsd authenticates every RPC request
individually. Most vendors don't do it as far as I know (I beleive it's
gonna be slow when you have a big /etc/exports).
While traditionally mountd is responsible for authentication, nfsd should
be "aware" of /etc/exports as well, as it needs to support various
mount options (readonly, root sqashing, etc). That also explains what
you have found.
Anyway, the problem you described is real -- once a filehandle becomes
known, an intruder may gain access, bypassing mountd. How bad the situation
varies, and depends on the nfsd implementation. For example, Linux's NFSD
would respond to any incoming readonly NFS request. However when a
write/modify request (of any kind) arrives it verifies the requesting host
has rw access, which disallows 'spoofed' write requests...
btw It just crossed my mind that the situation you describe, when a filesystem
is removed from /etc/exports, can be solved quite easily. If you remove
and re-mkdir your filesystem mountpoint (assuming it's not the root fs),
your mountpoint's filehandle will chage (due. to a new generation number).
And, (on a SunOS 4.1.x, but some others as well) since the filehandle
includes both the dev/inode/gen for the accessed inode AS WELL as the one
for its' filesystem mountpoint, this would change the filehandles for all
inodes(files) on that filesystem.
yossi.
