Document revision date: 19 July 1999

Although a security administrator may want to provide access to a common file, such as the payroll file described in Section 4.4.2, the administrator would want to ensure that only a limited number of people could use the letter-quality printer designated for printing checks. Otherwise, any holder of the payroll identifier could access the check forms that are always loaded in the printer TTA8.

Because the check printer in the current example is never used for logins and no queues are directed to it, the security administrator can add an ACL to the printer to ensure that only one user, McGrey, is allowed read and write access. At the same time, the administrator must block printer access for all other identifier holders. The following command sequence creates such an ACL:

$ SET SECURITY/ACL=((IDENTIFIER=MCGREY,ACCESS=READ+WRITE)- _$ (IDENTIFIER=*,ACCESS=NONE))/CLASS=DEVICE TTA8

While McGrey acquires read and write access, all other users are denied access with the NONE keyword, explained in Section 4.4.3. Still, the ACL on the printer TTA8 might not work exactly as intended until the security administrator modifies the printer's protection code. See Section 4.5.5 for details.

4.4.5 Limiting Access to an Environment

With an Identifier ACE, it is possible to provide conditional access by combining certain kinds of identifiers. A common situation is to use a UIC identifier with one of the environmental identifiers like batch or interactive. (For a complete list of environmental identifiers, see Section 4.1.6.1.) Thus, a user can access a protected object only when running in batch mode or interactively but never over a dialup line. For example, the next command grants user Fred both submit and manage access to a print queue, but only while he is running a batch job:

$ SET SECURITY/ACL=(IDENTIFIER=[FRED]+BATCH,ACCESS=SUBMIT+MANAGE)- _$ /CLASS=QUEUE SYSTEM6$LPA0

4.4.6 Ordering ACEs Within a List

An ACL can contain one entry or many entries. With multiple ACEs, the order of the entries is critical because the system determines access based on the first matching ACE. The operating system searches an ACL sequentially and grants a user the access specified in the first matching ACE, thus ignoring all subsequent entries. See Section 4.3 for a description of the evaluation process.

When writing ACLs, keep the following principles in mind:

• ACEs giving access to critical users belong at the top of the list.
• ACEs giving specific access to smaller groups belong before ACEs giving access to larger groups.
• ACEs giving more access rights belong before ACEs giving fewer access rights, unless you mean to selectively deny access.

The following ACL on the directory file PROJECT-ACCOUNTS.DIR demonstrates how to order entries in an ACL. It places ACEs giving access to critical users (Jones and Fred) at the top of the list and places general ACEs after them. The ACE denying access goes at the end.

$ SET SECURITY/ACL=( - _$ (IDENTIFIER=[ACCOUNTING,JONES],ACCESS=READ+WRITE+EXECUTE),- _$ (IDENTIFIER=[FRED]+BATCH,ACCESS=READ+WRITE+EXECUTE),- _$ (IDENTIFIER=PAYROLL,ACCESS=READ),- _$ (IDENTIFIER=DIALUP,ACCESS=NONE)) PROJECT-ACCOUNTS.DIR

The ACL on the project accounts directory allows read, write, and execute access to Jones all the time and to Fred while he is running a batch job. It gives read access to users holding the PAYROLL identifier. All users who are logging in from a modem are denied access unless they gain access through an earlier ACE. For example, Jones, Fred, or holders of the PAYROLL identifier might be dialing in, but, because their ACE precedes the DIALUP ACE, they would be granted access.

The next example shows an ACL for the data file STAFFING.DAT. It demonstrates how you place the entry providing the greatest amount of file access at the top of an ACL.

$ SET SECURITY/ACL=( - _$ (IDENTIFIER=SECURITY,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL),- _$ (IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE+EXECUTE+DELETE),- _$ (IDENTIFIER=SECRETARIES,ACCESS=READ+WRITE),- _$ (IDENTIFIER=[PUB,*],ACCESS=READ),- _$ (IDENTIFIER=NETWORK,ACCESS=NONE),- _$ (IDENTIFIER=[SALES,JONES],ACCESS=NONE)) STAFFING.DAT

In this ACL, any users holding the SECURITY identifier obtain maximum access rights through the first ACE, and users holding the PERSONNEL identifier have the next greatest access. User Jones is prohibited from any access to the file unless Jones also happens to hold one of the general identifiers. (This might be an oversight on the part of the creator of the ACL.) If you want to be absolutely certain that user Jones cannot gain access to the file, move the entry at the bottom of the ACL to the top.

4.4.7 Establishing an Inheritance Scheme for Files

You can create a plan for controlling access to files within a directory or a directory structure, develop an appropriate ACL for the files, and then direct the operating system to automatically assign this ACL to new files. To do this, create an Identifier ACE with the Default attribute, and then add the ACE to the directory file cataloging the files you want to affect. Use the OPTIONS keyword to include the Default attribute.

For example, if you want all new files in the directory [MALCOLM] to have an ACL entry that permits read and write access to users with the PERSONNEL

identifier, you can add the following ACE to the file MALCOLM.DIR:

$ SET SECURITY/ACL=(IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,- _$ ACCESS=READ+WRITE) [000000]MALCOLM.DIR

As a result of this ACE, any file created in the [MALCOLM] directory has the following ACL:

$ SHOW SECURITY APRIL_INTERVIEWS.TXT WORK_DISK$:[MALCOLM]APRIL_INTERVIEWS.TXT;1 object of class FILE Owner: [SALES,MALCOLM] Protection: ... Access Control List: (IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE) . . .

Notice that the Default attribute does not appear within a new file's ACL but only in the ACL of directory files. However, any subdirectory created in the MALCOLM directory automatically has the entry (IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,ACCESS=READ+WRITE) as part of its ACL. In this way, the ACE is propagated throughout the entire directory tree.

The ACE is not applied retroactively to existing versions of files in MALCOLM.DIR. To attach an ACE to existing files, you can use the /DEFAULT qualifier, described in Section 4.5.7, or use the following command:

$ SET SECURITY/ACL=(IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE)- _$ [MALCOLM]*.*;*

Any ACE with a Default attribute controls only the propagation of the ACE; it has no effect on access control. To control access to the directory as well as all its files, you have to insert two ACEs in the directory's ACL, as follows:

$ SET SECURITY/ACL=- _$ ((IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE),- _$ (IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,ACCESS=READ+WRITE))- _$ [000000]MALCOLM.DIR

4.4.8 Displaying ACLs

The DCL command SHOW SECURITY displays an object's ACL. When working with objects other than files, you must supply a class name as well as the object name. For example, the following display shows the security attributes of a device called PPA0. It is owned by the operating system, and its protection code gives full access (read, write, physical, and logical) to users in the system and owner categories but no access to group and world users; its ACL gives control access to user Svensen.

$ SHOW SECURITY /CLASS=DEVICE PPA0: _ACCOUNTS$PPA0: object of class DEVICE Owner: [SYSTEM] Protection: (System: RWPL, Owner: RWPL, Group, World) Access Control List: (IDENTIFIER=[ADMIN,SVENSEN],ACCESS=CONTROL)

There are many other ways of displaying ACLs. The access control list editor (ACL editor) is a useful tool for extensive work with ACLs; see the ACL editor documentation in the OpenVMS System Management Utilities Reference Manual. But any of the following DCL commands display ACLs:

	SHOW SECURITY
	DIRECTORY/ACL
	DIRECTORY/SECURITY
	DIRECTORY/FULL
	SHOW LOGICAL/FULL/STRUCTURE
	SHOW DEVICE/FULL
	SHOW QUEUE/FULL

Applications sometimes add a Hidden attribute to an ACE to indicate that the ACE should be changed only by the application that adds the ACE. Unless users have the SECURITY privilege, they cannot display a hidden ACE by using DCL commands. The ACL editor does display ACEs holding the Hidden attribute but only to show its relative position within the ACL; however, unauthorized users cannot edit the ACE.

Sometimes you see other kinds of ACEs, unrelated to access control, in an ACL. For example, if the security administrator places a security-auditing ACE on the LN03$PRINT queue, you will see an ACE at the top of the list that has the format (AUDIT=SECURITY,ACCESS=access-types). Such an ACE is part of the security-auditing system and has no effect on access, so you can ignore it.

4.4.9 Adding ACEs to an Existing ACL

Section 4.4.2 through Section 4.4.5 discuss how to add entries to an empty ACL with the DCL command SET SECURITY. To modify ACLs extensively, use the ACL editor; however, in many cases the SET SECURITY command is more appropriate. This section and those that follow describe how to use SET SECURITY to change an ACL.

To add more entries to an ACL, you can use the /ACL qualifier with the SET SECURITY command and specify the new ACEs. For example, to give the writers access to the print queue LN03$PRINT, use the following command:

$ SET SECURITY/CLASS=QUEUE/ACL=(IDENTIFIER=WRITERS,- _$ ACCESS=READ+WRITE) LN03$PRINT

By default, the system places the new ACE at the top of the ACL, as you see in the following SHOW SECURITY display:

$ SHOW SECURITY /CLASS=QUEUE LN03$PRINT _LN03$PRINT: object of class QUEUE Owner: [SYSTEM] Protection: (System: RWPL, Owner: RWPL, Group, World) Access Control List: (IDENTIFIER=WRITERS,ACCESS=READ+WRITE) (IDENTIFIER=[PUB,*],ACCESS=READ) (IDENTIFIER=NETWORK,ACCESS=NONE)

Because the default behavior for SET SECURITY is to place a new ACE at the top of an ACL, you need to use the /AFTER qualifier if you want to put the ACE in another position. For example, to position the TRADERS ACE in the queue's ACL after the WRITERS ACE:

$ SET SECURITY/CLASS=QUEUE/ACL=(IDENTIFIER=TRADERS,ACCESS=WRITE)- _$ /AFTER=(IDENTIFIER=WRITERS,ACCESS=READ+WRITE) LN03$PRINT

The resulting display confirms the effectiveness of the /AFTER qualifier. The new ACE is put second in the list.

$ SHOW SECURITY /CLASS=QUEUE LN03$PRINT _LN03$PRINT: object of class QUEUE Owner: [SYSTEM] Protection: (System: RWPL, Owner: RWPL, Group, World) Access Control List: (IDENTIFIER=WRITERS,ACCESS=READ+WRITE) (IDENTIFIER=TRADERS,ACCESS=WRITE) (IDENTIFIER=[PUB,*],ACCESS=READ) (IDENTIFIER=NETWORK,ACCESS=NONE)

4.4.10 Deleting an ACL

The /DELETE qualifier on the SET SECURITY command erases an ACL. Depending on how the qualifier is used, you can delete all or part of an ACL. For example, the following command deletes a disk's ACL:

$ SET SECURITY/CLASS=DEVICE/ACL/DELETE DUA0

An ACE can be protected against inadvertent deletion if it holds the Protected attribute. To eliminate a protected ACE, you need to delete it explicitly or use the /DELETE=ALL qualifier on the SET SECURITY/ACL command.

4.4.11 Deleting ACEs from an ACL

You can eliminate a subset of an ACL by listing the unwanted ACEs with the /ACL qualifier and including the /DELETE qualifier. For example, the following command deletes the ACEs giving holders of the TRADERS identifier and the NETWORK identifier write access to volume DBA0:

$ SET SECURITY/CLASS=VOLUME/ACL=- _$ (IDENTIFIER=TRADERS,ACCESS=WRITE),- _$ (IDENTIFIER=NETWORK,ACCESS=WRITE)/DELETE DBA0:

4.4.12 Replacing Part of an ACL

To replace one contiguous set of ACEs within an ACL with another set, specify the new ACEs with the /REPLACE qualifier and the ACEs to be deleted with the /ACL qualifier, as follows:

$ SET SECURITY/CLASS=VOLUME/ACL=(IDENTIFIER=TRADERS,ACCESS=WRITE)- _$ /REPLACE=((IDENTIFIER=RESEARCH,ACCESS=WRITE)- _$ (IDENTIFIER=STATE_DEPARTMENT,ACCESS=READ+WRITE),- _$ (IDENTIFIER=ENERGY_DEPARTMENT,ACCESS=READ+WRITE)- _$ DBA0:

The TRADERS ACE specified by /ACL is deleted. Following the deletion, the ACEs specified by the /REPLACE qualifier (RESEARCH, STATE_DEPARTMENT, ENERGY_DEPARTMENT) are inserted at the location of the old ACE.

4.4.13 Restoring a File's Default ACL

You can copy the security profile of one object to another by using the /LIKE qualifier to the SET SECURITY command. For example, you can save a complicated ACL on a nonpermanent object like a logical name table by copying it to a permanent object such as a file. Some administrators create a file to serve as a template in copy operations. This way, they can easily transfer an ACL from one object to another. For example, the following command copies the ACL from file ACL_TEMPLATE.TXT to the logical name table LNM$GROUP:

$ SET SECURITY/LIKE=NAME=ACL_TEMPLATE.TXT- _$ /COPY_ATTRIBUTE=ACL/CLASS=LOGICAL_NAME_TABLE LNM$GROUP

If you add the /COPY_ATTRIBUTE qualifier to the /LIKE qualifier, then you can copy one or two elements rather than the complete profile. Notice the ACL on the following directory, KITE_FLYING:

$ SHOW SECURITY [000000]KITE_FLYING.DIR;1 - WORK_DISK$:[000000]KITE_FLYING.DIR;1 object of class FILE Owner: [PROJECTX] Protection: (System: RWED, Owner: RWED, Group:, World) Access Control List: IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE IDENTIFIER=PROJECTX,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE

The following command copies the ACL from directory KITE_FLYING to the directory KITE_DESIGNS:

$ SET SECURITY/LIKE=KITE_FLYING.DIR;1 - _$ /COPY_ATTRIBUTE=ACL KITE_DESIGNS.DIR;1 $ SHOW SECURITY [000000]KITE_DESIGNS.DIR;1 - WORK_DISK$:[000000]KITE_DESIGNS.DIR;1 object of class FILE Owner: [ENGINEERING] Protection: (System: RWED, Owner: RWED, Group:R, World:R) Access Control List: IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE IDENTIFIER=PROJECTX,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE

The SET SECURITY/LIKE command does not always duplicate the entire ACL of the source object. For example, the command does not copy any ACEs from the source ACL that have the Nopropagate attribute. The command also does not overwrite protected ACEs. It preserves protected ACEs on the target object and adds them to the ACL being copied. (For example, applications often use a special type of protected ACE to explain how to display file data correctly, and these ACEs have to be preserved.)

Refer to the ACL editor documentation in the OpenVMS System Management Utilities Reference Manual for details on the different attributes an ACE can have, and refer to the OpenVMS Programming Concepts Manual for a description of all ACE types.

4.5 Controlling Access with Protection Codes

A protection code controls the type of access allowed (or denied) to a particular user or group of users. Access types identify the capabilities required to perform an operation on a protected object. The operating system can have multiple access requirements to complete an operation (see Section 4.7.2). A user can gain access to an object as soon as the operating system finds a category within the protection code for which the user qualifies that allows the access requested (provided an ACL does not deny access).

4.5.1 Format of a Protection Code

A protection code has the following format:

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

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:

• System: Members of this category can include any of the following:
  • Users with low group numbers, usually from 1 to 10 (octal). These group numbers are generally for system managers, security administrators, and system programmers. (The exact range of system group numbers is determined by the security administrator in the setting of the system parameter MAXSYSGROUP. It can range as high as 37776 (octal).)
  • Users with the SYSPRV privilege.
  • Users with the GRPPRV privilege whose UIC group matches the UIC group of the object's owner.
  • In access requests to files on a disk volume, users whose UIC matches the UIC of the volume's owner.
• Owner: The user with the same UIC as the user who currently owns the object. In general, the creator of an object is entitled to owner access unless explicit action is taken to secure the object from its creator.
• Group: All users who are in the same UIC group as the object's owner.
• World: All users, including those in the first three categories.

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

	privacy and legal statement
6346PRO_007.HTML