Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

file handle interpretation

0 views
Skip to first unread message

Leendert van Doorn

unread,
Dec 20, 1991, 7:40:16 AM12/20/91
to
j...@cs.strath.ac.uk (Jim Reid) writes:

# What about the generation number? Well, its usually 32 bits wide and
# essentially random (supposedly). However, good old NFS is kind enough
# to let you do a binary search. If the guess is too low the server will
# reply with NFSERR_STALE, so you can try the other half of the
# generation number space! This might generate a few 'bad file handle'
# messages on the system console, but by the time anyone can do
# something about it, you'll have a valid NFS file handle and can
# traverse through the filesystem at your leisure. Ho-hum.

NFS always returns NFSERR_STALE if it cannot convert a file handle into
a valid v-node pointer (see fhtovp()/nfs_server.c). This makes a binary
search impossible.

Leendert

--
Leendert van Doorn <leen...@cs.vu.nl>
Vrije Universiteit / Dept. of Maths. & Comp. Sc. +31 20 5484477
Amoeba project / De Boelelaan 1081A
1081 HV Amsterdam / The Netherlands

Barry Margolin

unread,
Dec 20, 1991, 6:35:50 PM12/20/91
to
In article <12...@star.cs.vu.nl> sa...@cs.vu.nl (Hans van Staveren) writes:
>die...@york.cs.ucla.edu (Dieter Rothmeier) writes:
>>What about the export file id? If a file system isn't exported you
>>can't get to it, period. Or is that only true for Sun implementations?

>Sorry, but the exports file is only used by the mount daemon. And why would you
>use the mount daemon if you can roll your own file handles?

Yes, the exports *file* is only used by the mount daemon (actually, in
SunOS it's the xtab file; /etc/exports is to /etc/xtab and
/usr/etc/exportfs as /etc/fstab is to /etc/mtab and /usr/etc/mount). But
structured versions of the export entries are also cached in the kernel,
for use by nfsd as described below.

>It would perhaps be possible to check the exports list at every NFS operation,
>but it would be expensive, and I doubt whether anyone has implemented it.

It's necessary to check the export entry to implement some access control
features. For instance, all NFS operations that try to modify the
filesystem must check whether the directory was exported read-write. And
when the client's uid is 0, nfsd must check the root= and anon= attributes
to determine how to translate the uid.

NFS servers that don't implement per-filesystem export properties such as
these can get away with leaving the export file id out of the file handle.
But SunOS can't.
--
Barry Margolin, Thinking Machines Corp.

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

Hans van Staveren

unread,
Dec 20, 1991, 4:22:30 AM12/20/91
to
die...@york.cs.ucla.edu (Dieter Rothmeier) writes:

>In article <JIM.91De...@hunter.cs.strath.ac.uk>, j...@cs.strath.ac.uk (Jim Reid) writes:
>|> In article <12...@star.cs.vu.nl> sa...@cs.vu.nl (Hans van Staveren) writes:

>[ deleted...]
>|> guess three things right: a device number, and inode number and a
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>|> generation number.
> ^^^^^^^^^^^^^^^^^

>What about the export file id? If a file system isn't exported you
>can't get to it, period. Or is that only true for Sun implementations?


>Dieter

Sorry, but the exports file is only used by the mount daemon. And why would you
use the mount daemon if you can roll your own file handles?

It would perhaps be possible to check the exports list at every NFS operation,


but it would be expensive, and I doubt whether anyone has implemented it.

Hans van Staveren

Dieter Rothmeier

unread,
Dec 20, 1991, 12:14:01 PM12/20/91
to


It's not that expensive. You just walk through a linked list which isn't
all that long. That's what Sun's NFS server does on every NFS operation.

Dieter

0 new messages