Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!ee.udel.edu From: new@ee.udel.edu (Darren New) Newsgroups: comp.os.misc Subject: Re: What constitutes a good OS? (re: file systems) Message-ID: <41760@nigel.ee.udel.edu> Date: 15 Jan 91 18:48:43 GMT References: <41679@nigel.ee.udel.edu> <1211@cvbnetPrime.COM> Sender: usenet@ee.udel.edu Organization: University of Delaware Lines: 134 Nntp-Posting-Host: sam.ee.udel.edu In article <1211@cvbnetPrime.COM> aperez@cvbnet.UUCP (Arturo Perez x6739) writes: >Well, actually, what I would like is a "method" for accessing the file that >is defined by the application that creates the file. Yes, that would be the UNIX-like way of doing it right (if I might be so bold). Keep the accessor out of the kernel. I've thought about this. The only problems would be these: 1) composible accessors, so you didn't have to reinvent the wheel if you wanted an encrypted, shared, record-oriented file. 2) security of the accessors: make sure that I could not circumvent your accessors to bypass your security. 3) a minimal set of functionality, so that a program like (say) vi could at least read a file, and preferably write it. For example, say that the accessor of a file would handle putting line numbers on each record in the editor such that each change did not renumber all the lines in the file and hence you could keep a listing around that would still have some connection to reality after the first change. How would the compiler ask the accessor program to get records back one at a time in the correct order? How would the compiler report errors by line number? >Records are pretty >bogus, if you ask me, because the OS has to maintain them when everyone knows >that the OS doesn't give a hoot about the internal structure of files. Baloney. The OS certainly cares about the internal structure of files we call directories, as well as the internal structure of block and some of the char special files, all of which are record-oriented. Our networks are record oriented (and we hide that via TCP, which X Windows then has to go break up again). Our disks are record oriented. Out tapes are record oriented. In addition, some of the OS that isn't in the kernel (login, for example) uses records in it's control files. About the only programs that don't talk about records are cp and rlogin. Other than that, I can't think offhand of any program that does not maintain some idea of record structure. Applications that really need random-accessed keyed files under UNIX tend to instead make a directory with files naming the keys. Observe, for instance, termcap. >In other >words, record-oriented filesystems are a kind of holdover because nobody knows >how to get the OS to do more than that; e.g, what would be more useful is a >"binary-tree" file for storing data with an associated "file call" rather than >an 80-byte record file where blah, blah, blah. No, records are there for the same reason that files are there: because they are a natural way of breaking up data. Any program that deals with less than an entire file at a time deals with records. I agree that a more sophisticated system than records would be useful. KSAM files, Mac-style resource forks, accessor functions, the FTAM virtual file store, etc could all be useful. I would be interested in discussing the 'ideal' system with anyone who might also be so inclined. >It's a sort of resource oriented approach to files whereby an application can >"install" a file-access method with the file. If there is no method the default >can be to read the file as a byte-array (or stream, if you prefer), write by >appending records sequentially. I agree, except that there should be a richer interface between the accessor and reader by default. Calls like "How would the user identify this record" leap to mind, in order that the compiler can answer in editor-specific line numbers for a source file, but a login-creator can answer with the user name, or whatever is used for the key in the /etc/passwd equivalent. >Another example would be backup information. It would be nice if a file "resource" >for last time backup'd could be included so that the backup program could use >something other than the date to decide whether to back a file up. This was one of the timestamps on CP/V: last backup date+time. You could show that to the operator and she could get the correct tape. Otherwise, you (the user) have no idea of when the most recent backup file was made. >Forgive my Macintosh weeny-OS >leanings here, but it is a good idea... I have nothing against the Mac OS (except that it was a pain to program back when I was programming Macs). I think there are many good ideas. Look how clean much of the system is simply by adding the idea of a resource fork (i.e., a keyed record-priented file system) to the OS. Now you can replace menus with other languages, add fonts to the system file, and so on, because it is built into the OS and every program can assume it is there and works. >> They have put the windowing stuff neither in the kernel, where you >> would expect it to have to work to be commercially viable, > >I am really curious about your statement and give the above as justification >for why I don't get it. I'm not trying to start an argument or anything! As I said in a previous post, I didn't recommend putting it in the kernel. I only meant that *if* it was in the kernel, it had better work well or people won't buy the system. >> I suspect that the security features of the file systems are just as >> bad as on UNIX too; however, I have no evidence to that effect except >> that they have kept the rest of the uglynesses too. > >I think my idea above might be able to offer a pretty good security system for >'sensitive' files. Except that it is up to each user to get it right unless you include some pretty sophisticated accessor functions that can be composed. CP/V was pretty good this way. Each file could have a list of accounts that could read, a list that could write, a list that could execute, a password, an encryption seed (not stored with the file, but the file would en/decrypt automatically if a seed was given), and an "under" language. Basically, if the file was executable but not readable and the user was running the "under" program, then that program, when it openned the file, would get an open file along with an error message saying the file is execute-only. The language would then take steps to keep the file from being examined incorrectly. (This could be used in UNIX to make execute-only shell scripts. You would just set the files perms to be read(none),execute(all),under(csh).) In practice, this was used to make BASIC and APL programs execute-only. Take, for example, and adventure game. You could simply set the file as above except under(adv) and only adventure could access the file. Under UNIX, you have to use SetUID, which requires either that you request the management to make a new account for this one program, or you have to be very careful that the ADV program never reads or writes any files except the exactly correct one. Only two levels of permissions in UNIX really makes for a difficult security system to get right, and we are still plagued with problems this simplistic mechanism has caused. -- 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 ... +=+=+=