After designing user groups and identifiers, you
need to address which protected objects your users need permission
to access and which ones can be unrestricted. Become familiar with
the default protection of new objects, shown in “Descriptions of Object Classes”Chapter 5,
and when necessary modify the defaults, as shown in the following
The procedure for setting up object protection
and ownership defaults varies, depending on whether the object is
a file or another class of protected object.
Controlling File Access
As “Profile Assignment”"Profile Assignment" on page 98
explains, there are four possible areas where you can specify protection
defaults that would affect the user. In order of increasing influence,
they are as follows:
The system parameter RMS_FILEPROT
sets the systemwide default for file protection. You can change the
value of RMS_FILEPROT with AUTOGEN. However, the effectiveness of
this value may be overridden by any of the following defaults.
The DCL command SET PROTECTION/DEFAULT
can specify the file protection placed on files created or modified
by the user during the terminal session. While the command typically
appears in the user's login command procedure, the user can also
enter this command at any time during a session to override the value
set by a previous SET PROTECTION/DEFAULT command. The SET PROTECTION/DEFAULT
command negates the influence of the systemwide protection for this
The default protection
for the specific directory can be specified in an ACL applied to the
directory. If a Default Protection ACE exists for the directory, all
new files added to the directory, including subdirectories and their
files, are subject to this protection code. This code overrides the
systemwide default and the user-specified default (if any).
In special cases where
the file being created is not owned by the user identification code
(UIC) of the process creating the file (for example, when a directory
is owned by a resource identifier), the default protection for the
new file can be modified by a Creator ACE within the directory's
ACL. See the“Profile Assignment”"Profile Assignment" on page 98 for a discussion of the Creator
Also consider the protection imposed on the volume through
the DCL command SET VOLUME/PROTECTION. This protection code, if specified,
prevents a user from accessing any part of the volume, regardless
of the protection code on the directory or the file. If no volume
protection is specified with the SET VOLUME command, the volume is
accessible to all users.
You may want to make adjustments to control default
behavior. The systemwide default protection code specified by the
system parameter RMS_FILE PROT sets the user's default protection
to the following:
Assume that the volume protection has been set
by the operator to the following:
The file protection on the directory [PROJECT]
has been set to the following:
If all the files created in the subdirectory [PROJECT.DIARY]
demand more protection, you, or any user who has control access to
the directory, could define a specific default protection code for
this specific directory with an ACL consisting of a Default Protection
ACE, as follows:
The following DCL command
would provide the desired default protection:
Once this ACE is placed on the directory file,
files created or modified in the directory are subject to the default
protection code. Because these protection codes are only defaults,
a user who has control access to a file in the directory can include
a specific protection code as a replacement for the default value
on the file by using the following DCL commands:
Once the default protection code is replaced,
the new code becomes the default and is propagated to subsequent versions
of the file.
If you provide a special login command procedure
for some of your users, you may want to supplement the systemwide
default process protection specified by the system parameter RMS_FILEPROT
for this group of users. Add the SET PROTECTION/DEFAULT command to
the login command procedure to specify the default process protection,
Files created in users' directories receive
this default protection code unless explicitly overridden.
Setting Defaults for a Directory Owned by a Resource Identifier
To allow for more flexible data management as
well as more accurate accounting of disk space, you can set up a directory
that is owned by a resource identifier and rely on ACLs to control
access to the directory and to files created within it.
The ACL can limit file access to all project members
holding the project identifier. To achieve this kind of access restriction,
you add an Identifier ACE to define the group's access to files.
A second Identifier ACE is added that duplicates the first but holds
the Default attribute. It is the Default attribute that ensures the
ACE is copied to all files created within the directory. Sometimes
a third ACE is necessary---a Default Protection ACE, depending on
the default protection code for the directory. A Default Protection
ACE establishes the protection code for the directory's files.
(As “How the System Determines if a User Can Access a Protected
Object”"How the System Determines If a User Can Access a Protected Object"
on page 74 explains, if an ACL denies access to a file, it is
still possible to gain access through a protection code.)
In addition to limiting the group's access
to files, an ACL can control the type of access users have to files
that they have created within the common directory. Because the file
is created in the resource identifier's directory, the resource
identifier owns the file. For users to access files they have created,
the operating system normally gives control access to the file's
creator plus the access specified in the owner field of the protection
code. However, you can modify this behavior by adding a Creator ACE
to the directory's ACL. A Creator ACE defines the type of access
users have to files they have created in the project's directory.
Setting Up the Resource Identifier
A security administrator used the following command
sequence to set up the project identifier PROJECTX and grant it to
members of the project. Notice that the identifier is added to the
rights database with the resource identifier, and it is also granted
to users with the resource identifier. The project identifier needs
to carry the Resource attribute so it can own disk space.
When a project- or department-specific identifier
is the owner of a directory, the space used by files created in the
directory can be charged to the appropriate department or project
rather than to the individual who creates them. When users work on
multiple projects, they can charge their disk space requirements to
the related project rather than to their personal accounts.
In setting up a directory for a resource identifier,
you first create the disk quota authorization for the project identifier.
For example, the following command invokes the System Management utility
(SYSMAN) and assigns the identifier PROJECTX 2000 blocks of disk quota
with 200 blocks of overdraft:
The Default Protection
ACE sets up a protection code for files created within the directory.
The ACE denies access to group and world users.
The first Identifier ACE
gives holders of the PROJECTX identifier read, write, and execute
access to the directory.
The second Identifier
ACE guarantees that all files created in the directory will carry
the first Identifier ACE.
The Creator ACE specifies
that a user who creates a file in the PROJECTX directory will receive
read, write, execute, and delete access to it.
Thus, when project member Ross creates the file
SEPTEMBER-REPORTS.TXT in the [PROJECTX] directory, the file receives
the following security profile:
$SHOW SECURITY/CLASS=FILE [PROJECTX]SEPTEMBER-REPORTS.TXTSEPTEMBER-REPORTS.TXT object of class FILEOwner: [PROJECTX]Protection: (System: RWED, Owner: RWED, Group, World)Access Control List:(IDENTIFIER=CRANDALL,ACCESS=READ+WRITE+EXECUTE+DELETE)(IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE)
Project members are not allowed to delete (or
control) files created by others; however, the Creator ACE gives them
delete access to files they have created.
Without a Creator ACE, project members each have
complete access to files they have created in the directory. For example,
Ross would receive the following access to files created in the project
$SHOW SECURITY/CLASS=FILE [PROJECTX]SEPTEMBER-REPORTS.TXTSEPTEMBER-REPORTS.TXT object of class FILEOwner: [ROSS]Protection: (System: RWED, Owner: RWED, Group, World)Access Control List:(IDENTIFIER=ROSS,OPTIONS=NOPROPAGATE,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)(IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE)
To negate this behavior, you can add a Creator
ACE to the ACL that specifies ACCESS=NONE.
Setting Defaults for Objects Other Than Files
With the exception of files and pseudo-terminal
(FT) devices, all classes of protected objects offer one or more template
profiles that provide security elements for new objects. You can thus
use a single mechanism to establish the default protection code, ACL,
and ownership elements for objects. The operating system always stores
these values so they are available from one system startup to the
next. The SHOW SECURITY command displays the current default values
for your particular site. See the “Descriptions of Object Classes”Chapter 5 for a listing of the
operating system's default values.
The operating system generates the security profiles
of new objects from data stored by security class objects. These objects
are all logical constructs used to keep track of such class elements
as the valid access types, the templates, and the types of auditing
that have been enabled. As “Security Class Object” shows, every class of protected object
has a member in the security class. All members have a security profile
template, except for files, which have their own rules.
Figure 8-4 Security Class Object
Displaying Class Defaults
To display any class template, use the SHOW SECURITY/CLASS=SECURITY_CLASS
command. The following command, for example, displays templates available
for logical name tables. The logical name table object has the following
All objects in the security class are protected
in the same manner as other objects. For this reason, any SHOW SECURITY
display of a security class object begins with the security profile
for the object itself. The following display shows a profile for the
logical name table object in the security class. The object is owned
by the system, and its protection code allows read access to any user
category but allows write access only to system and owner categories.
$SHOW SECURITY/CLASS=SECURITY_CLASS LOGICAL_NAME_TABLELOGICAL_NAME_TABLE object of class SECURITY_CLASSOwner: [SYSTEM]Protection: (System: RW, Owner: RW, Group: R, World: R)Access Control List: empty
Modifying Class Templates
Security administrators and users with control
access to a security class object can modify the elements of a given
template with the following command:
The following command modifies the MAILBOX template
for the device class. It changes the template values from a protection
of S:RWPL,O:RWPL,G:RWPL,W:RWPL to a protection that disallows group
and world access.
The operating system saves the default object
protections specified in security templates, so rebooting the system
automatically ensures that all objects created after the reboot are
created with the new default protections.
NOTE: In OpenVMS Version 7.2-1 and earlier, all pseudo-terminal
(FT) device protection codes were set by the driver to (S:RWLP,O:RWLP,G,W).
In OpenVMS Version 7.3 and later, only device FTA0 is set to this
forced protection. This allows the system manager the option of modifying
the FTA0 device protection later in the boot process. This new protection
is inherited from FTA0 by any new FT devices created thereafter (as
well as other settings originating from the SECURITY class DEVICE
TERMINAL template profile, such as ACLs).
A system manager can either modify FTA0 manually,
or change the SYSTARTUP_VMS.COM command procedure. For example:
$ SET SECURITY/CLASS=DEVICE -
_$ /PROTECTION=(S:RWLP,O:RWLP,G:RW,W:R) FTA0:
If the device protection for FTA0 is left unmodified,
the behavior is unchanged from versions of OpenVMS prior to Version
7.3. That behavior is that all terminals, except FT pseudo-terminal
devices, inherit their device protection and other security characteristics
from the TERMINAL template profile. All FTA pseudo-terminal devices
inherit their protection from FTA0, which by default is set to (S:RWLP,O:RWLP,G,W).
Other settings, such as ACLs, are inherited from the TERMINAL template
profile. This ensures compatibility with existing applications.