richard@aiai.ed.ac.uk (Richard Tobin) (08/15/90)
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
richard@aiai.ed.ac.uk (Richard Tobin) (08/16/90)
In article <3206@skye.ed.ac.uk> I wrote: >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 Jim Reid has pointed out to me that this is wrong. The client does actually seem to be doing a read from the server, but is passing it uid 0 (which gets translated to -2) instead of the owner's uid. -- 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
johnan@mchale.ism.isc.com (John Antypas) (08/18/90)
In article <3214@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >Jim Reid has pointed out to me that this is wrong. The client does >actually seem to be doing a read from the server, but is passing it >uid 0 (which gets translated to -2) instead of the owner's uid. Remember for most NFS versions that root gets translated to "nobody" for security reasons (according to Sun). Sun is aware that some hosts should be trusted and is including provisions for this in Sun OS 4.x. John Antypas / Interactive Systems Corp. uucp: ...!uunet!ism.isc.com!johnan Internet: johnan@ism.isc.com All statements above responsability of the author.