jss@sjuvax.UUCP (J. Shapiro) (03/23/85)
[Pacman's revenge...?] As one of the people who claim that there are things that can't be done under current UNIX even with libraries, let me clarify what I have problems with. It is certainly the case that libraries can perform all of the record management functions to support any record structure I am creative enough to invent. It is also clear that such libraries would be sufficient to prevent cooperating programs from trashing each other's data etc. In particular, this approach has the advantages that everyone has clamored for - there is no more overhead than the programmer imposes on himself. The problem with this comes in systems where data security is important, and it cannot be guaranteed that all programs are cooperating. By "noncooperating" I mean either 1. Programs actively seeking to compromise data integrity 2. Programs with honest programmer error - with the library approach it is easy to mistakenly access the record file through routines other than those in the library without thinking. In either case, there is much to be said for a notion in the file system of a record structured file - a file which can only be opened by a program using the correct record structure - that is, that which agrees with the files creation record structure. This makes actively compromising data nominally more difficult, and makes it quite impossible for a record structured file to be accessed using normal putc/getc style operations. By inserting this notion into the file system, it becomes instantly clear that another thing to add is verificationof data integrity - which relieves the programmer both of the burden of locking problems, and at the same time prevents mistaken malice. While I find the overhead of RMS to be burdensome as a programmer doing coding, I find it invaluable as an applications programmer - it provides me with a quaranteed secure way of handling the world. Particularly under UNIX, the overhead of writing routines to handle record structures in a secure fashion is so burdensome that I feel it belongs in the operating system. I remain skeptical that a secure record structured file can be implemented under UNIX. Comments? Jon Shapiro Haverford College
chris@umcp-cs.UUCP (Chris Torek) (03/27/85)
[This is a side (snide?) remark, NOT an answer!] > I remain skeptical that a secure record structured file can be > implemented under UNIX. Personally, I remain skeptical that a secure record structured file *has been* implemented *anywhere*.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
guy@rlgvax.UUCP (Guy Harris) (04/01/85)
> In either case, there is much to be said for a notion in the file system of > a record structured file - a file which can only be opened by a program > using the correct record structure - that is, that which agrees with the > files creation record structure. This makes actively compromising data > nominally more difficult, and makes it quite impossible for a record > structured file to be accessed using normal putc/getc style operations. RMS doesn't have this (definitely under RSX-11M, and probably under VMS). I can open the file with the appropriate QIO and write "I am a duck" all over your ISAM file. Under RSX-11M, RMS *IS* a library. Nothing more, nothing less. It runs in user mode (it doesn't run in kernel mode, and on an 11/40, or 11/34, or 11/23, or... user mode and kernel mode are all you have). Under VMS, it runs in "executive" mode. I don't know whether you have to be in "executive" mode to perform the QIO to open a file. > By inserting this notion into the file system, it becomes instantly clear that > another thing to add is verificationof data integrity - which relieves the > programmer both of the burden of locking problems, and at the same time > prevents mistaken malice. "Verification of data integrity"? Will the OS check that no withdrawal from a bank account exceeds the amount in the account (unless the account holder has overdraft privileges)? A lot of the burden of locking can be hidden by a properly written library. > While I find the overhead of RMS to be burdensome as a programmer doing > coding, I find it invaluable as an applications programmer - it provides me > with a quaranteed secure way of handling the world. "Guaranteed"? Under RSX-11M, I *know* there's no such guarantee, except by "security through obscurity" (the "open a file" QIO wasn't documented as of the last time I looked at RSX documentation). I suspect there's no such guarantee under VMS either. > Particularly under UNIX, the overhead of writing routines to handle record > structures in a secure fashion is so burdensome that I feel it belongs in > the operating system. 1) I think you meant "in the kernel". Just because it's in the operating system doesn't mean it's secure. 2) It's not a question of the size of the burden. It's either impossible to handle these structures securely, or it isn't. Under UNIX, and RSX, and probably VMS, and probably lots and lots and lots of other OSes, it's not possible, because the file abstraction the kernel provides is an array of bytes, or blocks, or whatever. > I remain skeptical that a secure record structured file can be implemented > under UNIX. I remain unconvinced that the security you demand is necessary. There are a heck of a lot of ways in which the file can be corrupted by operations which are perfectly legal from the standpoint of the record structure; depositing $10M dollars to the programmer's account is one of them. (We won't mention the fact that you may be placing more trust in the record management code in the kernel than it deserves.) As for the problem of poor programmers accidentally writing code that corrupts record structures: 1) If they only use the record management libraries (or if they write in a language like COBOL with the record management facilities built in), the chances of this are small. 2) The same argument about deliberate corruption of data without corrupting the record structure applies here as well. Guy Harris sun!guy