Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!wesommer@athena.mit.edu
From: wesommer@athena.mit.edu (Bill Sommerfeld)
Newsgroups: comp.unix.wizards
Subject: Re: NFS Security:  a summary
Message-ID: <7070@bloom-beacon.MIT.EDU>
Date: 15 Sep 88 02:35:28 GMT
References: <153@leibniz.UUCP> <43200038@uicsrd.csrd.uiuc.edu> <13457@mimsy.UUCP> <3e5d8f8f.13422@apollo.COM> <1487@ficc.uu.net>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: wesommer@athena.mit.edu (Bill Sommerfeld)
Organization: mit/project athena
Lines: 54
In-reply-to: peter@ficc.uu.net (Peter da Silva)

[ Disclaimer: "we" refers to Project Athena, not my current employer,
Apollo Computer ]

In article <1487@ficc.uu.net>, peter@ficc (Peter da Silva) writes:
>Just how heavy a load (in CPU power, throughput, and un-unix-like behaviour)
>does the system used by Project Athena impose?

CPU power needed: one hash table lookup based on source IP address and
the user ID in the source packet per NFS remote procedure call.  We
use a fairly stupid hash function (the sum of the "interesting" bytes
of the IP address and the user ID, modulo 256) as an index into a
256-element array; overflows are chained off in a linked list (which
should be self-reorganizing, but we never bothered to implement that).

Impact on throughput: not noticeable (although we're using VAX
11/750's as fileservers).

I'm not aware of any performance measurements; performance wasn't
really an issue--we had to do this, or else NFS would have been
unusable (for writeable files at least; we handle read-only files
through a different protocol).

By the way, last I checked, the side of the NFS protocol which checked
read-only mounts was the client, not the server.  Don't fool yourself
into thinking that you can export a partition read-only unless it is
mounted read-only _on the server_...

Un-UNIX like behavior: noticeable, but not particularly annoying.  The
biggest problem is doing an "su" in a remote directory which isn't
readable by "nobody".  The berkeley C shell exits SILENTLY if getwd()
fails at startup time (I think the code may actually print an error
message on stderr, but by that time the file descriptors may already
have been moved ..)

Also, because of a bug in the NFS protocol, you have to be sure that
your group set on both client and server match; extra groups on the
client results in "io errors", while extra groups on the server don't
give you any effective access (because the client didn't let you open
the file).

I must point out that it's not really secure--it's spoofable by people
who can set the source IP address on their packets, and it's downright
insecure if the client is a timesharing system (since anyone can send
UDP packets with arbitrary contents)--but it's good enough for an
academic environment, at least for the forseeable future.

					- Bill Sommerfeld
					(now with Apollo Computer, Inc.)

[When I'm done with my current project, I'm going to see if I can
browbeat apollo into doing the same thing for the domain filesystem.
Any apollo customers out there want to make a request for that
feature?]