On Tue, 28 Nov 2000, Warner Losh wrote:

# : Okay, is there a reason that getfh() shouldn't be mortal-enabled? It
# : already does path checking for accessibility; and since a stat() on a
# : non-readable file is ok, fhstat shouldn't be a problem, either.
# 
# stat on a non-readable file is a problem as it currently isn't
# allowed.

stat is most certainly allowed on a non-readable file!  How else would
ls(1) work?  :-)

# The talk on the FreeBSD side of the world is that these calls should
# quietly die a quick and sudden death.  They are fore the nfs server
# only and there are practicle problems with their use.  The problems
# aren't easily solved.  I'm not sure of all the details, but I thought
# I'd let the NetBSD community know what some in the FreeBSD community
# are thinknig.

Interesting.  I see the reasons given, and understand both your thought
and why they are not usable by mortal users (forgery is possible, i.e.).

Maybe it should be md5 summed with the path accessed or something; I
don't know.

Damn.  There's GOT to be a way to avoid the race condition; getfh() looked
so ideal.

I had considered something along similar lines when I first was using
UNIX -- it was called istat() or iopen() or something; this was immediately
shot down as a security breach (I was a newby, so it took me a while
to understand why this was so).

But there's GOT to be a way to avoid the race between stat() and open().
It works the OTHER way... :-)

# Warner

				--*greywolf;
--
Microsoft:  Living proof that Borg screw Ferengi.