drl@vuse.vanderbilt.edu (01/30/91)
Because the root userid is so powerful, the default behavior of NFS is to change all references from root on a client computer to be from the nobody user instead. You can bypass this security but this is the default. Unfortunately, since this is the only "unspoofable" user id, many files end up owned by root (to prevent NFS tampering) that would not need to be owned by root in a not-NFS environment. Is it possible to configure NFS to support a second userid switch so that the files that don't need to be owned by root can be owned by this second special ID? Is this a reasonable thing to want to do? David
guy@auspex.auspex.com (Guy Harris) (01/31/91)
>Is it possible to configure NFS to support a second userid switch so >that the files that don't need to be owned by root can be owned by this >second special ID? 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).
jfc@athena.mit.edu (John F Carr) (01/31/91)
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)