Path: utzoo!attcan!uunet!mcsun!ukc!edcastle!aiai!richard
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.protocols.nfs
Subject: NFS root access
Message-ID: <3206@skye.ed.ac.uk>
Date: 15 Aug 90 15:05:49 GMT
Reply-To: richard@aiai.UUCP (Richard Tobin)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 47

A well-known problem with NFS is as follows:

A file has mode (say) 0700.  On the local machine, this means that
only the owner and root can read it.  Typically, an NFS server 
translates uid 0 to -2, so remotely only the owner can read it.

Suppose a remote root tries to read the file.  The client assumes it
can (because root can read anything) and allows the open, but when it
tries to read the server returns "Permission denied".  Some programs
will report this error (albeit bizarrely: SunOS "cat" says "cat: write
error: Permission denied"), others (eg "more") are just silent.

If the owner of the file then tries to read it, he will likewise
get a "Permission denied" error, because the client has cached the
result of the NFS read, and the file attributes haven't changed.
Eventually, the data will become uncached, and the owner will be
able to read the file again.

The reverse effect now occurs: remote root can read the file,
because the client cached the result of the successful read by
the owner.

How could this be fixed?

That the permissions are interpreted by both the client and the
server seems wrong, since they may interpret them differently.
An NFS procedure to ask whether a particular operation would be
allowed would fix this, and the server could impose whatever 
constraints it liked.

A simpler, partial solution would be for the server to let remote root
read the file.  The current system is pointless: remote root can in
any case read the file by becoming the user, or by reading it while
the client kernel has it cached.  The following criterion provides
all the security that the current one does, without the caching
problem:

  Allow remote root to access the file unless the only local user who
  can access it is root.

Can anyone see a problem with this?

-- Richard
-- 
Richard Tobin,                       JANET: R.Tobin@uk.ac.ed             
AI Applications Institute,           ARPA:  R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin