|
HP OpenVMS Systemsask the wizard |
|
The Question is: Hello, I am looking for a way to allow users to create files, but once written, become read only, similar to a worm drive. Our users access the host in 2 ways: 1. through Reflection Terminal emulation which takes them directly into our application (no DCL access) 2. through NFS (Reflection NFS Connection) from a PC I have looked into assigning default file protection in a directory, but I'm not sure if I understand the implications of doing it that way. Can you help? Thanks! The Answer is :
This kind of storage area is fairly easy to do as a variation on the
"Project directory" as documented in the OpenVMS Guide to System
Security section 8.8.1.2. The files will be owned by a resource
identifier. Users will be able to create new files, and read them, but
will not be able to delete existing files. Note that due to OpenVMS
security rules, this means that users will not be able to create new
versions of existing files.
Here is a simple example. The resource identifier and directory are
called "TRAPDOOR" and the restricted user is called WIZARD:
$ MCR AUTHORIZE
UAF> ADD/IDENT TRAPDOOR/ATTRIBUTES=RESOURCE
%UAF-I-RDBADDMSG, identifier TRAPDOOR value %X80010070 added to rights database
UAF> GRANT/IDENT TRAPDOOR WIZARD/ATTRIBUTES=RESOURCE
%UAF-I-GRANTMSG, identifier TRAPDOOR granted to WIZARD
UAF> Exit
%UAF-I-NOMODS, no modifications made to system authorization file
%UAF-I-NAFNOMODS, no modifications made to network proxy database
%UAF-I-RDBDONEMSG, rights database modified
$ CREATE/DIRECTORY DKA100:[TRAPDOOR]/OWNER=TRAPDOOR
$ SET SECURITY DKA100:[000000]TRAPDOOR.DIR /ACL=( -
_$ (DEFAULT_PROTECTION,S:RWED,O:RWED,G,W),-
_$ (IDENTIFIER=TRAPDOOR,ACCESS=READ+WRITE+EXECUTE),-
_$ (IDENTIFIER=TRAPDOOR,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE),-
_$ (CREATOR,ACCESS=READ+EXECUTE))
Note that both the directory and DEFAULT ACE deny DELETE access and the
CREATOR ACE denies both DELETE and WRITE access.
From the users perspective:
$ create DKA100:[TRAPDOOR]AFILE.TXT
This file can be written. It will be owned by TRAPDOOR. It cannot be
deleted by the creator, only by someone with SYSTEM privileges. It
cannot be superceeded.
Exit
$ directory/security DKA100:[TRAPDOOR]AFILE.TXT
Directory DKA100:[TRAPDOOR]
AFILE.TXT;1 TRAPDOOR (RWED,RWED,,)
(IDENTIFIER=[USERS,WIZARD],OPTIONS=NOPROPAGATE,ACCESS=READ+EXECUTE)
(IDENTIFIER=TRAPDOOR,ACCESS=READ+WRITE+EXECUTE)
Total of 1 file.
$
$ type DKA100:[TRAPDOOR]AFILE.TXT
This file can be written. It will be owned by TRAPDOOR. It cannot be
deleted by the creator, only by someone with SYSTEM privileges. It
cannot be superceeded.
$ delete DKA100:[TRAPDOOR]AFILE.TXT;
%DELETE-W-FILNOTDEL, error deleting DKA100:[TRAPDOOR]AFILE.TXT;1
-RMS-E-PRV, insufficient privilege or file protection violation
$ create DKA100:[TRAPDOOR]AFILE.TXT
%CREATE-E-OPENOUT, error opening DKA100:[TRAPDOOR]AFILE.TXT; as output
-RMS-E-PRV, insufficient privilege or file protection violation
As an alternative, you can also use DECnet task-to-task to create
a privileged server, using either an executable image or DCL procedure
as the server. The caller passes a filename to a DECnet client task
(possibly embedded in your existing menu system), and the client then
passes a fully-qualified filename over to the server (potentially on
the same node), and the server then pulls the file over into a protected
(read-accessable) area. (This approach also permits the server to
establish the particular filename used.)
In either approach, remote NFS access adds another layer of mapping,
as the remote systems (the NFS clients) must be mapped into the
appropriate local user (in the NFS server). Either approach will
likely be easier if the files are "dropped off" using explicit local
access (via DCL in the menu, or via a DECnet task-to-task client in
the menu system), rather than files that are "dropped off" via direct
NFS (write) access.
|