Controlling Access with ACLs

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 HP 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 “Descriptions of Object Classes” 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:

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.

Granting Access to Particular Users

Because identifiers define the rights of individual users or groups of users (see “Types of Identifiers”), 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 “Ordering ACEs Within a List” for information on ordering ACEs.

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 “Ordering ACEs Within a List” 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 “How the System Determines if a User Can Access a Protected Object” and “Enhancing Protection for Sensitive Objects”, in particular].) Security administrators may also want to rescind privileges that can override the matching ACE.

Limiting Access to a Device

Although a security administrator may want to provide access to a common file, such as the payroll file described in “Granting Access to Particular Users”, 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 “Preventing Users from Accessing an Object”. Still, the ACL on the printer TTA8 might not work exactly as intended until the security administrator modifies the printer's protection code. See “Enhancing Protection for Sensitive Objects” for details.

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 “Types of Identifiers”.) 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

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 “How the System Determines if a User Can Access a Protected Object” for a description of the evaluation process.

When writing ACLs, keep the following principles in mind:

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.

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)
[vellip]

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 “Restoring a File's Default Security Profile”, 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

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 HP OpenVMS System Management Utilities Reference Manual. But any of the following DCL commands display ACLs:

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.

Adding ACEs to an Existing ACL

“Granting Access to Particular Users” through “Limiting Access to an Environment” 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.

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

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:

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, use the following command:

$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 QUEUEOwner: [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)

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.

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:

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.

Restoring a File's Default ACL

If you want to restore the default ACL to a file, you can use the /DEFAULT qualifier to the SET SECURITY command. This qualifier regenerates the full security profile for a file. See “Restoring a File's Default Security Profile” for a description.

Copying an 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=NAME=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.)

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