“Access Control List (ACL)” 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.
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:
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:
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.
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:
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:
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:
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:
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:
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.
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.
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:
As a result of this ACE, any file created in the
[MALCOLM] directory has the following ACL:
$SHOW SECURITY APRIL_INTERVIEWS.TXTWORK_DISK$:[MALCOLM]APRIL_INTERVIEWS.TXT;1 object of class FILEOwner: [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:
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:
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 DEVICEOwner: [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:
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.
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.
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 QUEUEOwner: [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:
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:
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:
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:
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 FILEOwner: [PROJECTX]Protection: (System: RWED, Owner: RWED, Group:, World)Access Control List:IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTEIDENTIFIER=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 FILEOwner: [ENGINEERING]Protection: (System: RWED, Owner: RWED, Group:R, World:R)Access Control List:IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTEIDENTIFIER=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.
