A possible security bug fix

[clark.wbst at PARC-MAXC.ARPA]

The main thing that makes UNIX "good" is it's elegance and simplicity.
These qualities have two advantages:

	1) It is easier to learn and remember how to use UNIX, and to
	   find bugs/interpret errors.

	   If you think about it, the documentation for UNIX is not real
	   extensive; yet from the time I started using it I never remember
	   feeling the unbelievable frustration I feel almost every day as
	   I try to get RSX, VMS, or good 'ol VersaDOS (Motorola) to do
	   what I want to do in spite of itself.  I have spent MONTHS
	   trying to do things that would have taken MINUTES on UNIX.

	   UNIX' indication of errors is not the best either.  System calls
	   have a tendency to return an informative -1, which is then
	   printed as some descriptive 3 word message as the utilitiy
	   exits.  To be fair(er), you can look at errno, but I never have.
	   The interesting point is that a stupid little -1 usually tells me
	   exactly what I need to know.  Such is not the case with the
	   many-digit (or letter equivilent) error number that comes out
	   of most operating systems, pointing you to a very specific
	   and extensive paragraph in an error code manual.   On such
	   systems I am usually almost as confused as before I looked,
	   or at best am not sure exactly what to do.  

	   Having the source is nice too, because you can look and see
	   exactly what the system does.  It beats reading an ambiguous
	   and voluminous pile of boring manuals.

	2) It does not restrict the user/programmer.  The system should
	   not (in my opinion) try to anticipate all applications and 
	   provide flexible facilities to do anything anyone might want
	   to do.  First because it gets rediculously complicated/BIG
	   and it takes a 5 year vetern to know all the ins and outs to be
	   able to use it efficiently and easily (i.e. to avoid spending
	   90% of your time plowing through manuals), but more
	   important, YOU CANNOT ANTICIPATE EVERYTHING 
	   ANYBODY MIGHT WANT TO DO!!!!!!!!  If you try, your 
	   result will get in the way of the poor sap (me) who just
	   wants to do something real simple, like open a file and read
	   it in 5 lines or less, or real the bits on a simple mag tape and
	   put them in a simple file.
	

This is changing as more and more simple little patches are made to 'fix'
'problems' that crop up.  Like 0,1, or 2 being closed.  Or funny bits in
the file name.  Sure, why not restrict it to printable ascii.  Seems reasonable.
But then, why not add an informative extention, so that people know what
a file contains without looking at it.  3 characters seems like enough.

Just a few more little details to remember, to get around... 

UNIX has this wonderfully elegant concept of 'standard I/O' if you 
will... The idea that you get the lowest free open file descriptor, and 
dup() dups them, and open opens them and close closes them... and fork
forks them too.... and exec propagates them... think about it - those simple 
ideas make the redirection of I/O and pipe ideas possible, in one easy 
swoop.  Very trivial, yet powerful idea.   And yet these pipes and > <
I/O redirection from the shell are what most non-UNIX types think of 
as UNIX!  They are just a creative application of the existing system
calls by the shell.  Do we really want to throw a monkey wrench in 
there by making an illogical/inconsistency in the basic design?
You would break most of my programs if it was changed so you could
not close 0,1, or 2.  I usually close them then open the file so I can use
printf.  

The other half of what makes UNIX great is the simple file system with 
no funny restrictions, and NO FILE TYPES, just byte stream files.  I 
fully anticipate that someone will shortly suggest that we really need 
to add fixed length records and variable length records and... in spite 
of the fact that with UNIX system calls all these could be implemented 
with 0-few lines of code.  But I am wandering.  The important point is 
that a file is just a pile of bits.  I don't give a * how the system keeps 
them, I just want them back in the same order.

Moral:

	Keep It Simple !   Or at least, please keep all the wierd stuff 
out of the kernel.  It should be kept clean, simple, and elegant.  If 
you want weird system calls, slide a layer of subroutines called 
wexec, wclose, etc. to do your funny stuff.  That way your 
application code won't be full of that code, and applications that
don't want it won't get it - they can implement what THEY need.

As UNIX gets more like VMS and VMS gets more like UNIX, I wish
something were getting more like an updated V6.

					--Ray Clark
					   Xerox, Webster N.Y.
					   {ucbvax!}Clark.wbst at parc-maxc