Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!clark.wbst@PARC-MAXC.ARPA From: clark.wbst@PARC-MAXC.ARPA@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: Re: A possible security bug fix Message-ID: <3718@sri-arpa.UUCP> Date: Tue, 2-Aug-83 09:18:00 EDT Article-I.D.: sri-arpa.3718 Posted: Tue Aug 2 09:18:00 1983 Date-Received: Fri, 5-Aug-83 04:48:54 EDT Lines: 90 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@parc-maxc