HP OpenVMS Systems Documentation
OpenVMS Guide to System Security
The first element of an object's security profile is the UIC of its owner.
In most cases, if you create an object, you are its owner. As the owner, you can modify its security profile. The system automatically assigns your UIC to the object and uses it in making access decisions.
There are some exceptions to the ownership rule. Files owned by resource identifiers do not have a UIC. When a user creates a file in the directory of a resource identifier, the file may be owned by the resource identifier and not the user who created the file (see Section 5.4.5). Refer to Chapter 5 for an explanation of the ownership rules for each object class.
The owner of any object except a file can reassign ownership to another
user with the SET SECURITY/OWNER command, as described in
Section 4.2.4. Changing the owner of a file usually requires privilege
(see Section 5.4.2).
The second element of an object's security profile is the object's protection code.
The system automatically assigns a protection code to each new object. The protection code associated with an object determines the type of access allowed to a user, based on the relationship between the user UIC and the owner UIC. With the exception of files and pseudo-terminal (FT) devices, the code a protected object receives is derived from a template profile for the class. (A file's protection code originates from another source, described in Section 5.4.)
Typically, you rely on the protection code to protect an object if the object is to be accessed by: (a) only the owner, (b) all users on the system, or (c) a specific UIC-based group of users. If you want to grant access to specific groups of users outside the UIC group but not to all users on the system, then you need to add an ACL (see Section 18.104.22.168).
A protection code defines the access rights for four categories of users: (a) the owner, (b) the users who share the same group UIC as the owner (the group category), (c) all users on the system (the world category), and (d) those with system privileges or rights (the system category). A code lists access rights in a fixed order: the system category (S), then owner (O), then group (G), and then world (W). It has the following syntax:
When the operating system processes a request to use a protected object, it compares the user's UIC to the UIC of the object's owner. If the user's UIC is the same as the UIC of the object's owner, the user is granted the access of the owner protection field. Failing a match of UICs, the system progresses through the other user categories. The system tries to find a match of the group fields to determine if there is a common group membership. The system may also evaluate whether the UIC group number indicates the user belongs to the system category of users. The world category applies to all users.
For example, user Jones has a UIC of [14,1], and he tries to read a file that is owned by UIC [14,5]. Because Jones is in the same group (14), the system might grant access to the file. The final decision depends on the access rights specified in the protection code.
The third (optional) element of an object's security profile is the object's access control list.
An access control list (ACL) is a collection of entries that define the access rights a user or group of users has to a particular protected object, such as a file, directory, or device.
ACLs may be created by default when an object is created, they may be created by the security administrator, or they may be created by users for objects to which they have control access (see Section 4.6.2).
Because security administrators can set up default ACLs, some users may be unaware that their objects have ACLs and may never change ACLs themselves. (You can use the DCL command DIRECTORY/SECURITY or SHOW SECURITY to see if there are ACLs on your files.) Other users are actively involved in creating and maintaining their own ACLs.
Using ACLs is optional. Although ACLs can enhance the security of objects in any installation through a more detailed definition of who is allowed what kind of access, users have to spend time creating and maintaining the ACLs.
To see the security profile of any protected object, use the DCL command SHOW SECURITY. For example, the following command requests security information about the file 93_FORECAST.TXT:
The display indicates the file 93_FORECAST.TXT is owned by user Greg.
It also lists the file's protection code, which gives read, write,
execute, and delete access to system users and the owner. The code
grants read and execute access to group users and provides no access to
world users. (See Section 4.5 for further explanation.) There is no
ACL on the file as yet.
You can provide new values for the owner, protection code, or ACL of a protected object or even copy a profile from one object to another by using the SET SECURITY command.
For example, the SHOW SECURITY display in Section 4.2.3 shows the file 93_FORECAST.TXT is owned by user Greg. As owner, he can change the protection code for that file. Originally, the code gave no access to users in the world category. Now, Greg changes that to allow read and write access to world users:
The SHOW SECURITY command verifies the new protection code for the file:
Section 4.2.5 shows how to modify other elements in a profile.
Section 4.4 and Section 4.5 discuss protection codes and ACLs
extensively. For a full description of the SET SECURITY and SHOW
SECURITY commands, see the OpenVMS DCL Dictionary.
Groups of objects that behave in a particular way and have a common set of attributes are divided into classes. Files, queues, and volumes are very common examples. As Table 4-2 shows, the operating system supports 11 classes of protected objects.
When you modify the profile of an object, you need to specify the class of the object; otherwise, the SET SECURITY command assumes the object is a file.
For example, the following command sequence changes the profile of an object and uses the /CLASS qualifier to identify the object LNM$GROUP as a logical name table:
The SET SECURITY command makes the Accounting group owner of the logical name table. It changes the protection code to allow read, write, create, and delete access for the owner and for system users and to limit group and world users to read access. Finally, it creates an ACL to allow control access for user Chekov and to allow read and write access for user Wu.
The SHOW SECURITY command displays the results of the changes.
To modify a security profile, you need control access to the object. An
ACL grants control access explicitly, whereas a protection code grants
it implicitly to anyone who belongs to the owner or system category.
(Refer to Section 4.6.2 for a full description of how you can acquire
When a user tries to access a protected object, the operating system calls the Check Protection ($CHKPRO) system service to compare the security profile of the user process with the security profile of the object. In the protection check, $CHKPRO compares the user's security profile against the protected object's profile using the following sequence:
Figure 4-3 charts the sequence the operating system follows when it evaluates an access request and shows how the controlling components (ACLs, protection codes, privileges, and access overrides) interact.
Figure 4-3 Flowchart of Access Request Evaluation
Section 22.214.171.124 introduced access control lists (ACLs) as one element of an object's security profile. This section explores this protection mechanism in depth and provides examples of how to use ACLs effectively to protect objects.
Many users do not need to bother with ACLs because the protection codes
that the operating system automatically assigns to objects are often
sufficient. But there are times when you need to allow specific users
access to your files, for example, when you are working on a common
project. Because ACLs are an effective mechanism for protecting
critical system files, devices, volumes, and other protected objects,
system managers and security administrators use ACLs more often than
Each entry in an access control list (ACL) is called an access control entry (ACE). An ACL can have many entries, each of which defines some attribute of an object. There are many kinds of ACEs, which you can read about in the OpenVMS System Management Utilities Reference Manual. Of interest here is the Identifier ACE, which controls access to objects.
An Identifier ACE includes one or more rights identifiers and a list of the types of access the users holding the identifier have permission to exercise. When the system evaluates a user's rights to an object, it scans the object's ACL until it finds an Identifier ACE that matches one or more rights identifiers held by the accessing user;2 it grants or denies access based on that entry.
The types of access that are granted (or denied) by an ACE depend on the object you are protecting. For example, you can read, write to, execute, and delete a file; whereas you can perform physical and logical operations on a device as well as reading and writing to it. Thus, a file supports read, write, execute, and delete access, and a device supports read, write, physical, and logical access. See Chapter 5 for information on the types of access other object classes support.
For example, to let user Fred read your file PROJECT-DATA.TXT, you would enter the following command:
The term FRED is the member name of a user identification code (UIC).
As such, it serves as a UIC identifier for the entry that grants user
Fred read access to the file PROJECT-DATA.TXT.
Because identifiers define the rights of individual users or groups of users (see Section 126.96.36.199), you use them in an Identifier ACE to define the access granted (or denied) to those who hold them. A UIC identifier easily identifies an individual user or a group of users on the system. When a group of users from diverse functional groups (and therefore, diverse UIC groups) all need access to a protected object, a security administrator creates a general identifier and grants the identifier to all the users who need access.
For example, the following command grants user Pat, who is identified by the UIC identifier [PAT], read, write, and execute access to a file located in the ROBERTS directory on DISK1. The ACL denies Pat delete and control access because it omits them from the access statement.
A security administrator uses the Authorize utility to create a general identifier and grant it to all users who need to use it. Assume, for example, that a security administrator has created and assigned the identifier PAYROLL to employees who need access to a payroll file. For the holders of the identifier to actually access the file, the administrator has to add an Identifier ACE to the file. For example, the following command creates an ACL for the PAYROLL file that gives holders of the PAYROLL identifier read access to the file:
Besides providing access to objects, an Identifier ACE is often used to deny certain users access to an object. Some sites might use an ACL to restrict users who log in from a modem or over the network. Other sites might place a restricting ACE on expensive equipment or volumes containing sensitive files.
To deny all access to holders of a particular identifier, use the NONE keyword as the access type name. For example, the following command denies holders of the environmental identifier DIALUP any access to the files in the PROJECT-ACCOUNTS directory:
Denying access with the NONE keyword requires some additional planning. You must position the ACE correctly in the ACL, as Section 4.4.6 describes, because the operating system grants or denies access based on the first matching ACE. (Alternatively, you can eliminate any access allowed through the group or world category of the protection code [see Section 4.3 and Section 4.5.5, in particular].) Security administrators may also want to rescind privileges that can override the matching ACE.