Definition of a Protected Object
The objects of the OpenVMS operating system that
require protection are all passive repositories that either contain
or receive information. These objects are protected because once you
have access to the object, you have access to the information it holds.
Some examples of protected objects include:
A file in memory or on
a storage device
A hardware device or a
A data structure, such
as a common event flag cluster or a logical name table
“Specifying an Object's Class” lists the classes of objects that
OpenVMS protects; see the “Descriptions of Object Classes” for an in-depth description of each
Contents of an Object's Profile
The security elements of any object comprise its security profile. An object's security profile contains
the following types of information:
The owner of the object. The system uses this element in interpreting
the protection code.
The protection code defining access to objects based on the
categories of system, owner, group, and world. This protection code
controls broad categories of users.
The access control list (ACL) controlling access to objects
by individual users or groups of users.
With the exception of files, a new object inherits
its security elements from a system-supplied template profile, which
the site security administrator may modify. Files have a more complicated
inheritance mechanism, one that affords greater control over the security
elements of new objects. In all cases, you can assign security elements
during object creation rather than using the operating system defaults.
This section gives an overview of protection codes
and ACLs. “Controlling Access with ACLs” and “Controlling Access with Protection Codes” explore these protection mechanisms
in greater detail. See the “Descriptions of Object Classes” for a description of individual object
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 “Profile Assignment”). See the “Descriptions of Object Classes” 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 “Modifying a Security Profile”. Changing the owner of a file usually
requires privilege (see “Types of Access”).
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
and pseudo-terminal (FT) devices, 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 “Files”.)
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 “Access Control List (ACL)”).
Interpreting a Protection
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
See “Controlling Access with Protection Codes” for a complete description of how
to interpret and create protection codes.
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 “Using Control Access to Modify an Object Profile”).
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.
“Controlling Access with ACLs” continues the discussion of ACLs
and how to use them.