[169] in linux-security and linux-alert archive
Re: Linux NFS client[
daemon@ATHENA.MIT.EDU (Alan Cox)
Wed Mar 15 12:21:40 1995
From: iialan@iifeak.swan.ac.uk (Alan Cox)
To: yogo@math.tau.ac.il (Yossi Gottlieb)
Date: Wed, 15 Mar 1995 14:45:07 +0000 (GMT)
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <199503141219.OAA13024@lune.math.tau.ac.il> from "Yossi Gottlieb" at Mar 14, 95 02:19:08 pm
> possibility for race conditions exists. For example, with current CLIENT
> implementation, it is possible to open a file on an NFS filesystem and while
> the file is open, erase it, and immediately replace it with a symlink. The
> symlink gets the same inode and most important, the same file handle of the
> original file (it may not necessarily be so, and depends on the server). Any
> futher writes to the file will go thru the symlink.
This is correct. Security is entirely the server end responsibility. In your
example if the symlink pointed to a read-only file the write would return
with an error. This is one of the areas where NFS does not have Unix semantics
If you can do that write to a read only file, notify your vendor, report it
to cert and get a fix.
> This is a HUGE security hole, and puts in danger both the client and the
> server. BSD handles this by disallowing NFS REMOVE calls on locally-open
No
> files. Instead, the file is renamed into something like ".nfsXXXX" (on SunOS
> anyway), which remains until the file is closed, and a real NFS REMOVE call
> is sent.
This is purely to improve the BSD semantics so that open/unlink/use-file/close
has the desired unix behaviour. For that reason your patch has a real use.
> btw Perhaps the SunOS nfsd have this behaviour, anybody can confirm/deny?
> While experimenting wit SunOS, I've noticed that whenever I try to replace
> an open file, any further writes to it causes a 'NFS Write Error' be sent
> to syslog, even though the syscall does not indicate any problem.
Thats because SunOS NFS works correctly. 8)
Alan
