Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site sjuvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!sjuvax!jss
From: jss@sjuvax.UUCP (J. Shapiro)
Newsgroups: net.arch
Subject: Record and File Locking
Message-ID: <993@sjuvax.UUCP>
Date: Fri, 22-Mar-85 23:30:07 EST
Article-I.D.: sjuvax.993
Posted: Fri Mar 22 23:30:07 1985
Date-Received: Mon, 25-Mar-85 01:45:57 EST
Organization: Saint Josephs Univ. Phila., Pa.
Lines: 45

[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