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 “Enabling Auditing for a Class of Objects”). 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).
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 “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:
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:
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:
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:
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:
DEFAULT_PROTECTION[,options],protection-code)
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:
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:
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:
The protection code is
propagated from the Default Protection ACE on the directory (if one
exists), or else it is propagated from the process default.
The ACL is propagated
from the parent directory for those ACEs that have the Default attribute.
The owner is set to the
owner of the parent directory. (Be aware that modifying a file's
owner generally requires privilege; see “Types of Access”.)
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.
