recent xenix flame

[shawn%mit-dspg at BRL.ARPA]

>From shawn Thu Jan  5 20:43:53 1984 remote from futura
To: bug-system
Subject: /dev/null


Its not clear what the 'right' thing to do here is, but it seems
that /dev/null (like in all other versions of unix), permits a program
to unlink it. This is generally bad. One reasonable thing to do, to
prevent this, is as follows:

1)	User program, (say an editor like elle), wan'ts to write to /dev/null,
	it makes a link to a '/dev/null.O' file, and unlinks /dev/null,
	then it writes out your data into the now DATA FILE /dev/null.

Ok, that's my problem, here's the fix:

Kernel gets 'unlink("/dev/null")',

Is file a special file? (yes), ok, then does it have the 'directory file bit'
set? No? then return error. anything else returns ok if the user has the
right access.

The basic idea is that on a special file, the directory bit is not used,
normally, (ok, some systems use it to hack with network software, but
this will not do any harm to even that type software).. and haveing to set
the d bit to a file, before being able to delete it, seems to be alot
better then haveing editors that don't know about /dev/null, and /dev/tty01,
etc, removeing DEVICE files, when people are hacking as root. I had this
happen, I must say, its somewhat strange to see a 100 block /dev/null.

			Yours In Hacking,
			  -- Shawn

p.s.
This letter is aimed at TRS-XENIX, by Radio (S)Hack, But I am
sending it off to the net world in hopes that someone might like it
and unix might adopt it, or someone will explain why this is a bad idea,
in any case, its my complete hope, tandy will addopt SOMETHING to keep
/dev/null from being removed, and '/dev/tty' is also a must.
(tandy and other vendors should know that THEY have to be 10* more careful
dealing with the general public).