Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!jfc
From: jfc@athena.mit.edu (John F Carr)
Newsgroups: comp.unix.internals
Subject: Re: a second "unspoofable" uid with NFS
Message-ID: <1991Jan31.014022.16134@athena.mit.edu>
Date: 31 Jan 91 01:40:22 GMT
References: <25758@adm.brl.mil> <5604@auspex.auspex.com>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
Lines: 26

In article <5604@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>It depends on the NFS implementation.  Most don't allow that, as far as
>I know; some may implement RFS-style user ID mapping (I think Cray
>originally proposed doing that; dunno if they implemented it in their
>server code).

We have been using NFS userid mapping here for almost 4 years.  Each NFS
request does a table lookup based on source host and uid to get the local
uid to use.  The mapping is done by another process, normally rpc.mountd.
Optionally, requests from unmapped users can be denied (we used to make our
sources world-readable, but put them on a machine which would only map users
authorized to read sources).  The NFS protocol does not define an equivalent
to the UNIX "access" system call, so there are problems when client and
server uids are different because the client kernel may deny access when the
server would allow it.  There are 2 solutions to this that have been
demonstrated here, but neither is in use (1: add an access check to the NFS
protocol, 2: perform the inverse of the uid map when returning file
attributes to a client).

rpc.mountd uses the Kerberos authentication system to set up the uid map.
At one time, source for the kernel uid mapping code and utilities was
available from the archive server on athena-dist.mit.edu.  I don't know if
it still is.

--
    John Carr (jfc@athena.mit.edu)