oakley%36975%1029%astro.span@SDS.SDSC.EDU (07/29/87)
It would be desirable if non-privileged programmers could control
access to their data files through the programs that they write. An
"end-user" could only access the data through the program - not
DCL or a program that the end-user might write. A solution to
this problem should NOT require the system manager to install the
non-privileged programmers image.
I have been thinking about how to provide this capability and
have some ideas. But I heard a rumor the other day that DEC was
going to provide this capability in a future release. The
capability would involve adding another kind of ACE. I attended
several futures sessions at Nashville, but never heard of this.
Has anyone heard of this capability being provided?
The approach I have tried involves a pair of user-written system
services that can be called from an application program. One
system service is used to change the process uic to that of the
uic of the image file. The second system service would restore
the process uic to what it was originally. A run-down handler
and control-C and control-Y handlers are also provided so that
the end-user could not escape to DCL with the wrong uic.
I have observed that VMS performs a protection check when a
file is opened, not when information in the file is
read/written/updated/deleted. Thus it would only be necessary
to change the process uic to open the file. The process uic
could be restored after the file is open.
Does anyone have any ideas or see any problems with this approach?
Has anyone ever done this, or is there a better solution? Thanks!
Mark Oakley
Battelle Memorial Institute
(614) 424-7154
ARPAnet: oakley%36975%1029%astro.span@sdsc-sds.ARPA
(I know this is a deadfully long address. We hope
to become an ARPAnet node in the near future.)dp@JASPER.PALLADIAN.COM (Jeffrey Del Papa) (07/31/87)
Date: Tue, 28 Jul 87 21:45:09 GMT
From: oakley%36975%1029%astro.span@Sdsc-Sds.Arpa
It would be desirable if non-privileged programmers could control
access to their data files through the programs that they write. An
"end-user" could only access the data through the program - not
DCL or a program that the end-user might write. A solution to
this problem should NOT require the system manager to install the
non-privileged programmers image.
I have been thinking about how to provide this capability and
have some ideas. But I heard a rumor the other day that DEC was
going to provide this capability in a future release. The
capability would involve adding another kind of ACE. I attended
several futures sessions at Nashville, but never heard of this.
Has anyone heard of this capability being provided?
Honeywell Multics (which has been abandoned) had this feature.
The approach I have tried involves a pair of user-written system
services that can be called from an application program. One
system service is used to change the process uic to that of the
uic of the image file. The second system service would restore
the process uic to what it was originally. A run-down handler
and control-C and control-Y handlers are also provided so that
the end-user could not escape to DCL with the wrong uic.
I have observed that VMS performs a protection check when a
file is opened, not when information in the file is
read/written/updated/deleted. Thus it would only be necessary
to change the process uic to open the file. The process uic
could be restored after the file is open.
Does anyone have any ideas or see any problems with this approach?
Has anyone ever done this, or is there a better solution? Thanks!
how do you protect the system services? (wsince you don't want to install
the image...]
Mark Oakley
Battelle Memorial Institute
(614) 424-7154
ARPAnet: oakley%36975%1029%astro.span@sdsc-sds.ARPA
(I know this is a deadfully long address. We hope
to become an ARPAnet node in the near future.)
<dp>Peck@RADC-MULTICS.ARPA (Rodney) (08/04/87)
oh please don't compare VMS to Multics. They are entirely different. Multics was designed from the beginning to have ACLs and Rings and two-dimentional segments. VMS has sort-of forced ACLS into DCL after 4 major revisions. Anyway, Multics has NOT been abandoned. Note my address. rodney peck II, a proud Multician.
dp@JASPER.PALLADIAN.COM (Jeffrey Del Papa) (08/04/87)
Date: Tue, 4 Aug 87 11:49 EDT
From: Rodney <Peck@RADC-MULTICS.ARPA>
oh please don't compare VMS to Multics. They are entirely different.
Multics was designed from the beginning to have ACLs and Rings and
two-dimentional segments. VMS has sort-of forced ACLS into DCL after 4
major revisions.
Anyway, Multics has NOT been abandoned. Note my address.
rodney peck II, a proud Multician.
it was supposed to be an example of something that got it right. the reference to
abandonment was from honeywells point.. last I heard, they shut the group down. I
assumed that there were still user sites (tho I think MIT is going soon)
<dp>kenw@noah.arc.CDN (Ken Wallewein) (08/05/87)
> It would be desirable if non-privileged programmers could control > access to their data files through the programs that they write. An > "end-user" could only access the data through the program - not > DCL or a program that the end-user might write. A solution to > this problem should NOT require the system manager to install the > non-privileged programmers image. You're talking about an application for one of my pet ideas: A way to access user-written software via a device driver. Consider: You define a logical for the file/service desired, and everyone opens it like a file. On the other end, maybe it opens a file, maybe it runs a program that opens a file, maybe something else. The server program may use it's own access control list, or whatever. A given piece of application software shouldn't need to distinguish between active and passive files. Just open it, do reads and writes, and close it. Who care what the actual data path is? Except... say you wanted your files to be encrypted, but you didn't want every application that accessed them to containg the encryption/decryption algorithms? Active files to the rescue! Your front end does it all. You could sort of fake it by using mailboxes and a detached process. However, access control is poor, and there is no way to do special open/close handling. Also read/write syncronization is very weak, and shared access could get rather tricky. What we want is transparency at the user level, right? I think such a piece of software would have so many uses we'll never be able anticipate them all. Come on, all you device driver hacks, what do you think? One of these days, if I ever learn enough about it, I way just write one myself! /kenw A L B E R T A Ken Wallewein R E S E A R C H C O U N C I L
MOSS@cs.umass.EDU ("Eliot Moss, GRC A351B, x5-4206") (08/06/87)
Funny you should talk about using a device driver to fire up a user program for access to files, etc. You see, years ago at an Institute not so far away (MIT), there was (still is perhaps) an operating system called ITS for the PDP-10 and its descendants. While definitely very much a home brew system full of hacks (even the name ITS is a joke: Incompatible Timesharing System; remember CTSS, the Compatible Time SHaring System?), ITS did provide a lot of advanced features. One was the ability to run many processes at once, organized as a tree in which each node could control its children. Another, relevant to the case at hand, was the ability to define new devices in software, that could do anything whatsoever (e.g., provide protected access to files -- except ITS has no protection, so why bother, unless maybe the active program decrypts an encrypted file, but beware! The source is probably accessible to everyone...) Anyway, it worked by causing a job to be fired off for each open on the device (called a JOB device, logically enough), and the job could then open the "other side" of the device (called the BOJ device) and extract details of each I/O request as they became available. The OS would translate all the possible requests to a smaller number of requests in canonial form, simplifying the BOJ device end, and would also handle providing the data back to the client (as well as accepting data for writes). I actually wrote one of these; it displayed a laser printer spooler queue as I recall. Anyway, it's been done before; you could probably get the spec to get ideas on what is necessary; and I think it's a great idea to try to build one for VMS! Eliot Moss