charlie@cca.UUCP (06/21/83)
On our system (4.1bsd VAX) under heavy load, /dev/null is often not empty; in fact it contains sometimes interesting stuff belonging to some other user. Have others experienced this? Is there a fix? The command "cat /dev/null" illustrates the problem about 1/3 of the time here.
mb@root44.UUCP (06/22/83)
I've seen the same problem on an ONYX that had not had the permissions on /dev set properly. Once your handy neighbourhood moron has typed 'rm /dev/null' and got away with it, you see all sorts of interesting stuff in response to 'cat /dev/null' until the next 'if grep xxx foo >/dev/null; then .....' clears it out again. Quit honestly, the state of access permissions on a lot of commercially available U*IX is a disaster. The ONYX is no worse than others. Perhaps somebody out there would like to write a shell script that gets things about right and then post it somewhere handy to save us all a lot of time? I don't suppose it will happen, but one can dream. Mike Banahan.
smk@linus.UUCP (Steven M. Kramer) (06/24/83)
Someone has as part of the LINUS III secure UNIX package (me).
I don't want to distribute the whole package yet, but a sample
is in net.sources. It is called integrity and checks file permissions
against those in a file. It does the job but is currently
inefficient (it should use dbm(3) and ndir(3)).
--
--steve kramer
{allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!smk (UUCP)
linus!smk@mitre-bedford (ARPA)ellis@flairvax.UUCP (06/25/83)
Our 4.1bsd system will let me create a file called '/dev/null' if
I am running as root. The original fake device is thereby destroyed.
This has accidentally happened to me several times. Same goes for
'/dev/tty', which can cause REAL problems.
As far as I can see, there is no reason to allow this to happen.
Anyone else familiar with this problem ? Suggestions - Solutions ?
Michael Ellis - Fairchild AI Lab - Palo Alto CA - (415) 858 4270ron%brl-bmd@sri-unix.UUCP (06/26/83)
From: Ron Natalie <ron@brl-bmd> According to both the BSD, UNIX V7, and experimentation with our system, the creat on an existing writable file will not modify the owner, mode, or change the file type from special to regular, but merely attempt to truncate it to zero length (regardless of whether the invoker was root or not). My observation is the only way to zap /dev/null is to remove it first. My previous employer also had some marvelous utility for going around and checking on the placement, modes, and owners of system files. He's going to be at the Toronto giving a talk on a related topic of his. The name in Martin McGowan from CCI. I don't have any network mail addresses for him. -Ron