Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!uwm.edu!psuvax1!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.unix.wizards
Subject: Re: tty security problems under SunOS 4.1 and SunOS 4.1.1
Message-ID: <16178@smoke.brl.mil>
Date: 17 May 91 04:37:04 GMT
Article-I.D.: smoke.16178
References: <16155@smoke.brl.mil> <7491:May1502:05:3291@kramden.acf.nyu.edu> <19283@rpp386.cactus.org>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 20

In article <19283@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
>NFS is by far the biggest hole on the planet ...

Quite possibly true.  This week Moss & I discovered yet another in a long,
continuing series of NFS deficiencies.  We had an application that locked
a file, did some I/O to it, and truncated it to final length.  (Basically,
deleting records from a database.)  In one case the final length was 0
bytes, which was correctly shown by a subsequent "ls" command, but
amazingly if one "cat"ted the file quite a bit of data was "read",
different data each time.  Our theory is that the local NFS buffer cache
was not being coordinated with the remote inode that was affected by the
ftruncate() system call.  (Yes, we had lock and stat daemons running on
both local and remote hosts.)  The data that could be "read" from the
supposedly 0-length file had to be coming from somewhere in the kernel,
presumably from a block buffer cache.  This would be an interesting way
to snoop on the contents of files that one was not supposed to be able to
access..

P.S.  SunOS 4.0.3 (local) and Irix 3.3.1 (remote), if somebody wants to
try to track this down.