[171] in linux-security and linux-alert archive
Re: Linux NFS client
daemon@ATHENA.MIT.EDU (Yossi Gottlieb)
Thu Mar 16 13:17:19 1995
From: Yossi Gottlieb <yogo@math.tau.ac.il>
To: linux-security@tarsier.cv.nrao.edu
Date: Thu, 16 Mar 1995 16:46:34 +0200 (GMT+0200)
In-Reply-To: <m0rouJw-00012kC@iiit.swan.ac.uk> from "Alan Cox" at Mar 15, 95 02:45:07 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.
What about suid programs? In their case, the critical part (on regular fs)
is until a file is open; once it's open, there's no way to replace the file
with a symlink, etc. On NFS this is not true.
Tricking an suid root program will allow write on any file (unless the
filesystem is exported with no root access)... that's under Linux, no vendor
to notify... :)
> > 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)
SunOS NFS doesn't have the problem since the Sun NFS server doesn't 'recycle'
filehandles. I suspect it achives this by keeping a random number on the
inode record (on disk), and creates a new number whenever an inode is
allocated. When creating a filehandle, it stuff that number into the fh
together with the inode number, that's why create-erase-create won't return
the same filehandle, even if the same inode is used.
Can't prove this yet, though... :)
yossi.
