Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: Unexpected NFS Effects
Message-ID: <1860@auspex.auspex.com>
Date: 28 Jun 89 20:36:27 GMT
References: <403@fang.dsto.oz> <12025@bloom-beacon.MIT.EDU> <1703@softway.oz>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 14

>So that's how it is, I'm sure. The question now is "Why?". I can't think
>of any reason why you couldn't pass a "read for execution" request distinct
>from a "read as data" request.

Even if you could, it wouldn't provide real security - just write
user-level NFS client code (not too painful) that "reads" a file by
using "read for execution" requests.

In other words, don't assume packets coming into your server are being
generated by a "trusted" source, unless you have some way of verifying
that.  I know of another remote file system that, as far as I can tell,
trusts requests to some degree, and would let me open a file for
reading and then make "write" requests to it, simply by generating the
messages myself rather than going through the kernel code....