Document revision date: 19 July 1999

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).

4.2.2.2 Protection Code

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, 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 4.2.2.3).

Interpreting a Protection Code

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:

[user category: access allowed (,user category: access allowed,...)]

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.

See Section 4.5 for a complete description of how to interpret and create protection codes.

4.2.2.3 Access Control List (ACL)

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.

You use the DCL commands SET SECURITY and SHOW SECURITY for creating and displaying ACLs, although the access control list editor (ACL editor) is an important utility for more extensive work.

Section 4.4 continues the discussion of ACLs and how to use them.

4.2.3 Displaying a Security Profile

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:

$ SHOW SECURITY 93_FORECAST.TXT WORK_DISK$:[GREG]93_FORECAST.TXT;1 object of class FILE Owner: [ACCOUNTING,GREG] Protection: (System: RWED, Owner: RWED, Group: RE, World) Access Control List: <empty>

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.

4.2.4 Modifying a Security Profile

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:

$ SET SECURITY/PROTECTION=(W:RW) 93_FORECAST.TXT

The SHOW SECURITY command verifies the new protection code for the file:

$ SHOW SECURITY 93_FORECAST.TXT 93_FORECAST.TXT object of class FILE Owner: [GREG] Protection: (System: RWED, Owner: RWED, Group: RE, World: RW) Access Control List: <empty>

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.

4.2.5 Specifying an Object's Class

Groups of objects that behave in a particular way and have a common set of attributes are subset 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:

$ SET SECURITY /CLASS=LOGICAL_NAME_TABLE- _$ /OWNER=ACCOUNTING /PROTECTION=(S:RWCD, O:RWCD, G:R, W:R)- _$ /ACL=((IDENTIFIER=CHEKOV,ACCESS=CONTROL),- _$ (IDENTIFIER=WU,ACCESS=READ+WRITE)) LNM$GROUP

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.

$ SHOW SECURITY LNM$GROUP /CLASS=LOGICAL_NAME_TABLE LNM$GROUP object of class LOGICAL_NAME_TABLE Owner: [ACCOUNTING] Protection: (System: RWCD, Owner: RWCD, Group: R, World: R) Access Control List: (IDENTIFIER=[USER,CHEKOV],ACCESS=CONTROL) (IDENTIFIER=[USER,WU],ACCESS=READ+WRITE)

Table 4-2 Classes of Protected Objects

Class Name	Definition
Capability	A resource to which the system controls access; currently, the only defined capability is the vector processor.
Common event flag cluster	A set of 32 event flags that enable cooperating processes to post event notifications to each other.
Device	A class of peripherals connected to a processor that are capable of receiving, storing, or transmitting data.
File	Files-11 On-Disk Structure Level 2 (ODS-2) files and directories.
Group global section	A shareable memory section potentially available to all processes in the same group.
Logical name table	A shareable table of logical names and their equivalence names for the system or a particular group.
Queue	A set of jobs to be processed in a batch, terminal, server, or print job queue.
Resource domain	A namespace controlling access to the lock manager's resources.
Security class	A data structure containing the elements and management routines for all members of the security class.
System global section	A shareable memory section potentially available to all processes in the system.
Volume	A mass storage medium, such as a disk or tape, that is in ODS-2 format. Volumes contain files and may be mounted on devices.

Refer to Chapter 5 for a detailed description of each class.

4.2.6 Access Required to Modify a Profile

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 control access.)

4.3 How the System Determines If a User Can Access a Protected Object

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:

1. Evaluate the access control list (ACL).
   If the object has an ACL, the system scans it, looking for an entry that matches any of the user's rights identifiers. If a matching access control entry (ACE) is found, the system either grants or denies access, and further checking of the ACL stops.
   When the matching ACE denies access, a user can still gain access through the system and owner fields of the protection code or through privilege. When an ACL has no matching ACE, the system checks all fields of the protection code.
2. Evaluate the protection code. If the ACL did not grant access and the object's owner UIC is not zero,¹ the operating system evaluates the protection code. The operating system grants or denies access based on the relationship between the user's identification code (UIC) and the object's protection code.
   For cases where an ACL has denied access, the system examines two fields in the protection code---the system and owner fields---to determine if the user is allowed access. The user can still acquire access by being a member of the system or owner categories or by possessing privileges. A user holding GRPPRV (with a matching group UIC) or SYSPRV is granted the access specified for the system category of the protection code.
3. Look for special privileges.
   If access was not granted by the ACL or the protection code, privileges are evaluated.
   Users with certain system privileges may be entitled to access regardless of the protection offered by the ACLs or the protection code. The bypass privilege (BYPASS), group privilege (GRPPRV), read all privilege (READALL), or system privilege (SYSPRV) amplifies the holder's access to objects. (See Section 4.6.1 for more information on how privileges affect access.)

4. Consider access overrides.
   For some object classes, access may be granted based on alternate privileges. For example, the queue object allows full access to all queues for users with operator privilege (OPER), and the logical name table object allows access to the system table for users with system name privilege (SYSNAM).

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

4.4 Controlling Access with ACLs

Section 4.2.2.3 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 general users.

4.4.1 Using Identifier Access Control Entries (ACEs)

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;² 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.

To create an ACL with an Identifier ACE, use the DCL command SET SECURITY in the following format:

SET SECURITY/ACL=(IDENTIFIER=identifier,ACCESS=access-type)

For example, to let user Fred read your file PROJECT-DATA.TXT, you would enter the following command:

$ SET SECURITY/ACL=(IDENTIFIER=FRED,ACCESS=READ) PROJECT-DATA.TXT

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.

4.4.2 Granting Access to Particular Users

Because identifiers define the rights of individual users or groups of users (see Section 4.1.6.1), 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.

$ SET SECURITY/ACL=(IDENTIFIER=[PAT],ACCESS=READ+WRITE+EXECUTE)- _$ DISK1:[ROBERTS]JULY-SALES.TXT

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:

$ SET SECURITY/ACL=(IDENTIFIER=PAYROLL,ACCESS=READ) PAYROLL.DAT

The order of ACEs in an ACL is important because of the operating system's processing rules. See Section 4.4.6 for information on ordering ACEs.

4.4.3 Preventing Users from Accessing an Object

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:

$ SET SECURITY/ACL=(IDENTIFIER=DIALUP,ACCESS=NONE)- _$ /CLASS=FILE PROJECT-ACCOUNTS.DIR

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.

	privacy and legal statement
6346PRO_006.HTML