Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!trwatf!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.arch
Subject: Re: Record and File Locking
Message-ID: <598@rlgvax.UUCP>
Date: Mon, 1-Apr-85 01:01:58 EST
Article-I.D.: rlgvax.598
Posted: Mon Apr  1 01:01:58 1985
Date-Received: Fri, 5-Apr-85 10:45:37 EST
References: <993@sjuvax.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 71

> 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