Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!wuarchive!udel!ee.udel.edu From: new@ee.udel.edu (Darren New) Newsgroups: comp.os.misc Subject: Re: What constitutes a good OS? Message-ID: <41902@nigel.ee.udel.edu> Date: 16 Jan 91 21:08:33 GMT References: <5258@auspex.auspex.com> <41772@nigel.ee.udel.edu> <5293@auspex.auspex.com> Sender: usenet@ee.udel.edu Organization: University of Delaware Lines: 258 Nntp-Posting-Host: estelle.ee.udel.edu In article <5293@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: [many questions related to but mostly orthagonal to the points I tried to make] >I have no great problem with the former complaint (I haven't needed an >ISAM package for what I've done, but others do use it). I'm not sure >what having line numbers built into the lines buys you, though. The ability to change a file without invalidating all the hardcopies you may have of the file. The same problem leads documentors to include "this page intentionally left blank" so all indexes don't have to be changed every time a page is inserted. *I* have used both and *I* prefer line numbers. I never missed line numbers in a system where I would never look at a hardcopy (like Smalltalk). >I think it's incorrect to state that they want records, too; they want >lines, and generally don't care whether the lines are defined as "a >bunch of bytes with a (LF/CR-LF/CR) at the end" or "a byte count >followed by the bytes of the line". Either is fine. I'm considering lines and records to be the same thing here. I don't know why you think I want a particular format for records or lines, if you do. >Lines, not records. Why don't you tell me the difference as you see it. I don't understand what this statement is implying. >why do you want embedded line numbers? See above. If I get ten error messages from the compiler, I have to fix them in reverse order lest the line numbers get changed while I edit. Increasing more-sophisticated tools can be used to overcome this problem (like a tool that intersperses error messages into the source file), but I believe this to be curing the symptoms. >No, it doesn't; indeed, programs that don't understand record boundaries >can't always deal properly with tapes. However, programs that *do* >understand tape blocks *can* deal with disk files as well as tapes; >e.g., "tar" and "cpio" can maintain their archives directly on tape or >on a disk file, which is quite useful (consider the number of FTP-able >or UUCP-able packages archived as possibly-compress "tar" files). No dispute there. Certainly UNIX is elegant in that many utilities can be made to work on unexpected inputs because everything is a file. My point is only that the file access metaphor is not what I would have chosen. Tapes are a superset of byte streams. Windows are a superset of byte streams (hence SIGWINCH). Processes are supersets of byte streams. Everything out there is a superset of a byte stream. If you force an application to access your device as a bytestream, you can get contorted interfaces (like all the different names for my one tape drive) but your tools work. If you allow an application to access your device in a non-bytestream way (like some windowing systems where things are calls rather than streams), none of your tools work. I believe that with a higher lowest common denominator, both of the above problems could be avoided. Nothing prevents you from *also* allowing access as a bytestream: withness the stream-oriented access to the Macintosh resource forks, which allows uploading and copying of structured files. >>The terminal, the mouse, and the windows are not >>files. Sure, you can make an interface to them that looks like a file, >>but that is the same thing as making records on top of keyed files, >I don't think you meant that, unless "making records on top of keyed >files" means something quite non-obvious. Sorry. I meant "making records on top of stream files". Brain damage, you know. I promise to proof-read my posts better in the future. The point is that the access to the mouse as a file is bogus because the mouse is not a memory-like device. If I read it now, I'll get a different answer that if I read it later. Either that, or I have information piling up and out of date. The mouse is an active entity, and if you want to access everything as a file, then files should be active also. >Yes, but I don't see why that's a problem. Programs that read and write >text files can generally read and write the terminal as well. Again, no argument from me. I'm not against having devices all be readable as files. I object to the simplicity of the interface between the user and the files. This simplicity leads (IMHO) to elegance of simple tools but reinvention of the wheel on larger programs. >Yes, but I'm not sure why this renders the fact that you access the >mouse by opening "/dev/mouse" and doing "read()" calls from it at all >bad. Same point. I object to the lack of records, not to the mouse being a file. >Either you read a different paper, or don't remember right; the paper I probably misremember. I don't remember a bitblt file, but a /dev/cons file with a bitblt IOCTL. Oh well. >1) it might make it possible to trace the window system actions being > performed by your program by interposing something like "tee" between > it and "/dev/bitblt"; Very useful. >2) even if it doesn't look exactly like a disk file, the fact that it (or > other kinds of objects) exists in the same *namespace* as files, and > supports some subset of the same kinds of operations, can be useful > if for no other reason that multiple kinds of these specialized > objects behave similarly (e.g., the low-level screen bitblt code and > the window-system bitblt-in-a-window code). Bingo! Sophisticated devices support a *superset*, not a subset, of what stream-oriented files can do. However, there is no way in UNIX of accessing these enhanced features except through the one IOCTL call, (vastly overloaded and widely varying from release to release let alone vendor to vendor,) and that IOCTL cannot be used by most tools. Also, file names themselves play an important part of the I/O behaviour of a file object, which seems really strange to me (the tape device comes to mind). >Note that the key thing here isn't purely the file-like behavior; the >notion that many types of objects inherit behavior from some common >class is part of it. It may be that "file" isn't the right class, >but.... No, that forcing the behaviour of everything to be accessed via the behaviour of (almost) the simplest file structure imaginable is the problem. >>On top of that, we put TCP to make it reliable. Many protocols I've seen put >>records on top of TCP, because the behaviour is inherently record- >>oriented. > >Which, of course, says nothing about the advantages of >byte-stream-orientation vs. record-orientation in UNIX; the >byte-stream-orientation vs. record-orientation is a characteristic of >the protocol. Right. The file access mode is inherently tied up with the file you are accessing. Hence, you have to go through extra work to put the lower-level structure (IP), as hidden by the higher level structure (TCP), back. By using TCP for reliability, you lose the advantages of a record-oriented file, and have to rebuild it from streams. RPC went the other way, and used the records of UDP and had to tack the reliability back on top. >>Say what?! It fits the name-space model OK, but the idea that >>/proc/1406/status is a file containing an ASCII representation >>of the CPU time used so far is nothing to do with a process being >>a file. > >Yup, it's more that a process is a *directory*. :-) Right. Here, we substitute "file" for the word "record" and "directory" for the word "keyed file". Other points deleted because you are right. >>Lack of ACLs; lack of file passwords; >Why are file passwords a good idea? I'm genuinely curious; what do they >buy you that either > 1) file encryption with a password Costs time on every read/write to encrypt/decrypt. Others can still make a copy or even destory it if no ACLs are provided. Difficult to change while file is open (like a TP file which stays open all the time), hence making security breaches a bigger problem. Passwords (I assumed) were checked only at open time and could be changed while the file is open, much like UNIX mode bits. > 2) some access control mechanism like file modes or ACLs I can tell you the password and have you give it to whomever needs it. I can't do that with an ACL, unless one of the flags of the ACL says who is allowed to change the ACL, which is probably the best solution of all. I have no objection to both ACLs and passwords and encryption -- each for the appropriate use. >>for non-privledged stuff (i.e., setUID) >I presume here you mean "i.e., not setUID". I meant "non-privledged" as in "not superuser". If I want to give limited access to a file without first obtaining superuser privledges for some length of time, I need to make a setUID program, which then has my permissions when accessing *any* file. >Or perhas you mean "privileged stuff (i.e., setUID)"; i.e., if you write a >set-UID program, there's no good way to verify that it's secure? Yes, that. >Or you *did* mean non-privileged stuff, and the complaint is that you >don't know that running some J. Random program won't trash *your* stuff? I think that as long as I don't set *any* of my programs to setUID and nobody with root privledges messes up a setuid program owned by the root, then I'm acceptably safe from Jay's programs. As it currently stands, with only one level of privledge, setUID programs must be hand crafted to achive the goals. To step outside the rwxrwxrwx sophistication requires hand-crafting of a setUID program. Stepping outside of more complex ACLs also requires hand-crafting some sort of application program to control access, but I think it is much more rare and much easier to assure that it will at worst mung only files associated with the given application when the ACLs are indeed sufficiently powerful. Also, with only one level of privledge, it is easy to accidentally cause a major lossage, like archiving the tape to the disk partition :-(. As a counter-example, CP/V had the following privledge levels (probably amongst others): 00 -- could run startup command only, could not read/write any files not explicitly permitted in the file's ACL. 10 -- added: could run programs in the system directory naming this account 20 -- added: could read/write files owned by that account and files read(public). 30 -- added: could run own programs 40 -- normal privledges. added: could read files marked read(all), etc 50 -- could list accounts. equiv of being able to ls /usr. 60 -- could list files in other accounts (ls -l of otherwise-non-readable dirs). 80 -- could read any memory (like ps). 90 -- could read any non-passworded file not owned by "root" A0 -- could read any file (used for backups) B0 -- could write any file C0 -- could write any memory, all privledge checking disabled. (Superuser, including the ability to bump privledge still further.) D0 -- untracked resorce allocation (could request pages from disk w/o putting in file, pages of memory that stick around when program exits, etc) E0 -- Realtime control, ability to turn off task switching, etc. Using the right level for the right job prevented many problems. I personally saw the system saved from crashes at least three times because the sysprog had boosted his privs only to what he needed to implement and test system program being worked on. >>lack of any good network security; etc. >To what sort of network security are you referring here? Security >problems with allowing network access to files without providing some >network authentication scheme such as Kerberos or the "DES >authentication" scheme in ONC RPC? Well, the ACLs in UNIX are still non-network ACLs for the most part. We have {user, group, and the entire universe} access. Why not {user, group, machine, local net, world} accesses? It would be nice to be able to put something up for anon FTP that anybody at University of Delaware could download but that nobody else could download. Kerberos works, but I don't know that it addresses the problems of which I am thinking as it seems to allow setUID programs (say, the mail server) to confirm that the caller is as represented (and vica versa). It does nothing to allow me, Darren New, to let only certain files be accessed by Jay Random. These two problems are orthagonal. We still have problems with internet worms, passwords in anonymous-FTPable files, and so on. How far would the internet worm have gotten if the only files it was allowed to access were those that were explicitly read(ftpd)? -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- =+=+=+ Let GROPE be an N-tuple where ... +=+=+=