  Creating read-only files? 
 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&gt; ADD/IDENT TRAPDOOR/ATTRIBUTES=RESOURCE
    %UAF-I-RDBADDMSG, identifier TRAPDOOR value %X80010070 added to rights database
    UAF&gt; GRANT/IDENT TRAPDOOR WIZARD/ATTRIBUTES=RESOURCE
    %UAF-I-GRANTMSG, identifier TRAPDOOR granted to WIZARD
    UAF&gt;  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.
 
