Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rochester!rutgers!ucla-cs!zen!ucbvax!SDS.SDSC.EDU!oakley%36975%1029%astro.span From: oakley%36975%1029%astro.span@SDS.SDSC.EDU Newsgroups: comp.os.vms Subject: Protected access to data files Message-ID: <870728214511.00l@Sds.Sdsc.Edu> Date: Tue, 28-Jul-87 17:45:09 EDT Article-I.D.: Sds.870728214511.00l Posted: Tue Jul 28 17:45:09 1987 Date-Received: Sat, 1-Aug-87 15:33:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 39 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.)