Controlling Access with Protection Codes

Format of a Protection Code

A protection code has the following format:

user category

User categories include system (S), owner (O), group (G), and world (W). Each category can be abbreviated to its first character. Categories have the following definitions:

When specifying more than one user category, separate the categories with commas, and enclose the entire code in parentheses. You can specify user categories and access types in any order (although the system always displays them in the order system, owner, group, world).

To deny all access to a user category, specify the user category without any access types. Omit the colon after the user category when you are denying access to a category of users.

Omitting a category entirely means access to the category is unspecified. The current access allowed that category of user remains unchanged. If the protection code applies to an object being created (for example, with a COPY/PROTECTION command), the omitted category is assigned the default value.

access-list

Access types are object-dependent and are described in “Descriptions of Object Classes”. For files, the access types include read (R), write (W), execute (E), and delete (D). The access type is assigned to each user category and is separated from its user category by a colon (:), for example, SET SECURITY/PROTECTION=(S:RWE,O:RWE,G:RE,W).

Types of Access in a Protection Code

Each category of user can be allowed or denied different types of access. The exact type is dependent on the object being protected. Each object class defines access types appropriate for its class and representative of the ways in which users operate on the data. For example, while the file object supports read, write, execute, and delete access, devices (such as terminals, printers, and disks) support read, write, physical I/O, and logical I/O access. See “Descriptions of Object Classes” for a listing of the access types each object class supports.

All protected objects also support control access, which allows a user to examine and modify the security elements (ACL, protection code, UIC) and possibly other attributes of the object. Control access is explicitly stated in an ACL but never appears in the UIC-based protection code. All users who qualify for the system or owner categories of a protection code have control access. Users in the group and world categories never receive control access through a protection code, but they could receive access through an ACL. See “Using Control Access to Modify an Object Profile” for more information.

The capabilities conveyed by the access types read, write, execute, delete, and control vary depending on the situation where they apply. For example, execute access permits different operations depending on whether it is granted for file access or directory access. “Descriptions of Object Classes” explains the capabilities that each access type allows for each type of protected object.

Processing a Protection Code

When the system evaluates a protection code, it looks first at the owner field, then at the world field, the group field, and finally the system field. As soon as a user qualifies as a member of the category and that category grants the necessary access, the operating system stops processing the code (see “Flowchart of Access Request Evaluation”).

The following protection code specifies that users in the system and owner categories have read (R), write (W), execute (E), and delete (D) access, while users in the group and world categories have only read and execute access:

$SET SECURITY/PROTECTION=(SYSTEM:RWED, OWNER:RWED, GROUP:RE, WORLD:RE)-
_$TAXES_91.DAT

When you want to deny access to a user category, you must deny access to all the outermost categories. As “Format of a Protection Code” shows, any user process or application qualifies for world access. The group category is more restrictive yet not as restrictive as the owner and system categories.

The following protection code, for example, appears to deny delete access to the owner category:

$SHOW SECURITY TAXES_91.DAT

WORK_DISK$:[GREG]TAXES_91.DAT;1 object of class FILE

     Owner: [FINANCE,GREG]
     Protection: (System: RWED, Owner: RW, Group:RW, World:RWED)
     Access Control List: ...

However, the owner of the file can still delete the file. Although delete access is not allowed through the owner category, the system continues to check the remaining categories for permission to grant access. Because the owner also fits in the world category (which applies to all users) and the world category is permitted delete access, the system grants delete access to the owner.

Changing a Protection Code

You can change the UIC-based protection on an existing object with the SET SECURITY command. The following command modifies the protection code of the file SURVEY.DIR so that anyone in the system and owner categories has read, write, execute, and delete access; whereas members of the group and world categories have read and execute access:

$SET SECURITY/PROTECTION=(SYSTEM:RWED,OWNER:RWED, -
_$GROUP:RE,WORLD:RE)  SURVEY.DIR

Whenever you omit a category from a protection code, the current access remains unchanged. For example, consider the protection code for the file RECORDS_91.DAT:

$SHOW SECURITY RECORDS_91.DAT

WORK_DISK$:[GREG]RECORDS_91.DAT object of class FILE
     Owner: [VMS,GREG]
     Protection: (System: RWED, Owner: RWED, Group: RWED, World: RE)

As it stands, the file RECORDS_91 allows read, write, execute, and delete access to users in the system, owner, and group categories; it allows read and execute access to users in the world category. The following DCL command resets the protection code for RECORDS_91.DAT to deny write and delete access to the group category and to deny all access to the world category:

$SET SECURITY/PROTECTION=(G:RE,W) RECORDS_91.DAT

The next command confirms the modified protection code. It shows that the system and owner categories of users continue to hold read, write, execute, and delete access, while group users have only read and execute access and world users have no access.

$SHOW SECURITY RECORDS_91.DAT

WORK_DISK$:[GREG]RECORDS_91.DAT object of class FILE
     Owner: [VMS,GREG]
     Protection: (System: RWED, Owner: RWED, Group: RE, World:)

Enhancing Protection for Sensitive Objects

“Limiting Access to a Device” describes how to place an ACL on an important printer so that only one user can have access to it. Before the ACL can be effective, however, the security administrator has to eliminate all access provided through the printer's protection code by using the following command:

$SET SECURITY/PROTECTION=(S,O,G,W)/CLASS=DEVICE TTA8:

The security administrator then uses an ACL to assign access explicitly.

For example, to limit access to a queue, you can remove submit access for the world category. Then you can set up an ACL that specifies which users (from the world category) are permitted to submit jobs to the queue. The following command stipulates that only holders of the identifier PROJECTX can submit jobs to the LN03$PRINT queue:

$SET SECURITY/CLASS=QUEUE/PROTECTION=(W) -
_$/ACL=(IDENTIFIER=PROJECTX,ACCESS=SUBMIT) -
_$LN03$PRINT

Important files frequently need special protection. You can prevent users from seeing the contents of a directory by denying them read access. To further protect the files, you can add a Default Protection ACE to the directory file, as “Providing a Default Protection Code for a Directory Structure” describes.

Providing a Default Protection Code for a Directory Structure

To specify default protection for new files in a particular directory, place a Default Protection ACE in the ACL of the directory file. The Default Protection ACE affects files that are subsequently created in the directory and in any subdirectories under that directory unless protection is specified for one of those files individually. This ACE type has the following format:

For example, the following ACE specifies that users in the system and owner categories have read, write, execute, and delete access to any files subsequently created in the directory and that group and world users have no access:

$SET SECURITY/ACL=(DEFAULT_PROTECTION,S:RWED,O:RWED,G,W) ARCHIVE.DIR

Be aware that the default protection is associated only with newly created files -- not existing files in the current directory and its subdirectories. If you add a Default Protection ACE to a directory file and want the same protection applied to existing files, you must explicitly change the protection with the following command:

$SET DEFAULT [ARCHIVE]
$SET SECURITY/PROTECTION=(S:RWED,O:RWED,G,W) [...]*.*;*

Restoring a File's Default Security Profile

The /DEFAULT qualifier of the SET SECURITY command regenerates the security profile of a file. The /DEFAULT qualifier resets the protection code, the ACL, and the owner elements of the file to the defaults specified by the file's parent directory (that is, to the directory's default ACL, default protection ACE, if any, and owner UIC).

The profile is recreated according to the following rules:

With subdirectory files, SET SECURITY assigns the owner, protection, and ACL elements of the parent directory.

SET SECURITY does not copy any ACE on the source object if it holds the Nopropagate attribute, nor does it change any ACE on the target object if it holds the Protected attribute. To apply new elements to all versions of the file, specify ;* in the object name.

See the “Profile Assignment” for more information on propagation rules.