Document revision date: 19 July 1999

This chapter describes the unique features of each class of protected object: files, volumes, devices, and so on. Each class description contains information on the following topics:

Topic	Description
Naming rules	A summary of naming conventions for objects in the class.
Types of access	Access types supported for the class. Boldface type indicates the abbreviation of an access type, such as R for read access.
Template profile	The default profile applied to new objects of the class. Site security administrators can modify the default profiles. Use the SHOW SECURITY command to display current template settings.
Privilege requirements	Privileges, if any, required for certain operations on the object.
Kinds of auditing performed	Events that trigger an audit event message (assuming the event class is enabled).
Permanence of the object	Storage of security profiles. Explains if the security elements are stored from one system startup to another and if so, where the elements are stored.

If a given topic does not apply to a class, the topic is omitted.

5.1 Capabilities

A capability is a resource to which a site controls access, using the standard access control mechanisms. The ability to execute vector instructions is a capability object. Only sites with a vector processor have such an object.

5.1.1 Naming Rules

The only valid name for a capability object is VECTOR.

5.1.2 Types of Access

The capability class supports the following types of access:

Use	Gives a process the right to make use of the vector processor
Control	Gives you the right to change the protection and ownership elements of the object

5.1.3 Template Profile

The capability class provides the following template profile:

Template Name	Owner UIC	Protection Code
DEFAULT	[SYSTEM]	S:U,O:U,G:U,W:U

Modifications to the VECTOR template take effect the next time you boot the system. If you want to change the elements of the VECTOR object after the system is booted, you must modify the object directly. For example:

$ SET SECURITY/CLASS=CAPABILITY/PROTECTION=(S:U,O:U,G:U,W) VECTOR

5.1.4 Kinds of Auditing Performed

The operating system can audit the following type of event:

Event Audited	When Audit Occurs
Access	The first time after image activation that the process uses a vector instruction

5.1.5 Permanence of the Object

The capability object's security profile needs to be reset each time the system starts up.

5.2 Common Event Flag Clusters

A common event flag cluster is a set of 32 event flags that enable cooperating processes to post event notifications to each other.

Event flags in the cluster can be set or cleared to indicate the occurrence of an event. All event flags are contained within clusters of 32 event flags, and each process has access to four clusters (numbered 0 through 3). Two of the clusters are local to a single process. Event flag clusters 2 and 3 are called common event flag clusters and are used for interprocess synchronization. A subject may be associated with up to two common event flag clusters. Each common event flag in a cluster is referenced by an event flag number.

5.2.1 Naming Rules

The name of the object is whatever character string was supplied as an argument to the Associate Common Event Flag Cluster system service ($ASCEFC). Remember that common event flag cluster names are qualified by your UIC group number.

5.2.2 Types of Access

The common event flag cluster class supports the following types of access:

Associate	Gives a process the right to establish an association with the named cluster so the process can access event flags.
Delete	Gives a process the right to mark a permanent event flag cluster for deletion with the Delete Common Event Flag Cluster ($DLCEFC) system service. The actual deletion occurs once all processes disassociate from the cluster.
Control	Gives you the right to modify the protection elements of the common event flag cluster.

5.2.3 Template Profile

The common event flag cluster class provides one template profile. Although the template assigns an owner UIC of [0,0], this value is only temporary. As soon as the object is created, the operating system replaces a 0 value with the value in the corresponding field of the creating process's UIC.

Template Name	Owner UIC	Protection Code
DEFAULT	[0,0]	S:AD,O:AD,G:A,W

When the process creating the common event flag cluster supplies a prot argument to $ASCEFC that has a value of 1, then the system modifies the template so the process UIC is the owner, and the protection code denies group access.

5.2.4 Privilege Requirements

Creation of a permanent common event flag cluster requires the PRMCEB privilege. This privilege also grants delete access for permanent clusters.

5.2.5 Kinds of Auditing Performed

The system can audit the following types of events:

Event Audited	When Audit Occurs
Creation	When the first process to associate with a particular cluster calls $ASCEFC
Access	Whenever subsequent callers to $ASCEFC associate with the cluster
Deaccess	When a process calls $DACEFC or associates with another cluster or at image rundown
Deletion	When the process calls $DLCEFC

5.2.6 Permanence of the Object

A common event flag cluster and its security profile need to be reset each time a system starts up.

5.3 Devices

A device is a peripheral, physically connected or logically known to a processor and capable of receiving, storing, or transmitting data. A device can be physical, like a disk or terminal, or it can be virtual, like a mailbox or pseudoterminal. Virtual devices are implemented entirely in software.

5.3.1 Naming Rules

You can use physical, logical, or generic names to refer to devices. In addition, if your system is part of a clustered system, certain devices are accessible to all members of the cluster. They have the following formats:

• Most physical device names consist of three parts:
  • A device code (dd), which represents the hardware device type.
  • A controller designator (c), which identifies the hardware controller to which the device is attached.
  • The unit number (U), which uniquely identifies a device on a particular controller.
  
  The maximum length of the device name field, including the controller and the unit number, is 15 characters.
• Logical device names equate the somewhat cryptic physical device name to a short, meaningful name. You can use these logical device names, rather than the physical device names, to refer to devices.
• A generic device name consists of the device code and omits the specific controller or unit number.
• A cluster device name includes the name of the node to which the device is attached and the physical device name, separated by a dollar sign ($).

See the OpenVMS System Manager's Manual and the OpenVMS User's Manual for a full description of device names.

5.3.2 Types of Access

Devices can be shared and thus have concurrent users or be unshared and have a single user.

Shared devices support the following types of access:

Read	Gives you the right to read data from the device
Write	Gives you the right to write data to the device
Physical	Gives you the right to perform physical I/O operations to the device
Logical	Gives you the right to perform logical I/O operations to the device
Control	Gives you the right to change the protection elements and owner of the device

Unshared devices support only read, write, and control access. The device driver rather than the operating system's security policy defines the access requirements for other types of operations.

5.3.3 Access Requirements for I/O Operations

Access requirements for I/O operations on devices can be quite complex. The following list explains access requirements for typical operations:

• Assigning a channel with $ASSIGN
  Assigning a channel to a nonspooled, nonshareable device requires read access, write access, control access, or any combination. Assigning a channel to a shareable device has no access requirement.
• Allocating a device with $ALLOC
  Allocating any device with $ALLOC requires read, write, or control access.
• $QIO to spooled devices
  Access is handled as described for OpenVMS mounted volumes. See the next list item, $QIO to file-oriented devices.
• $QIO to file-oriented devices: disks and tapes
  With file-oriented devices, logical I/O and physical I/O functions have common elements. Any logical I/O function requires physical or logical access plus read access to read a block (READLBLK) or write access to write a block (WRITELBLK). Any physical I/O function requires physical access plus either read access to read a block (READPBLK) or write access to write a block (WRITEPBLK). Logical and physical I/O also require LOG_IO and PHY_IO privileges, respectively.
  Beyond this, access requirements depend on how the volume is mounted:
  • OpenVMS supported volumes
    Any virtual I/O to the volume has the same access requirements as the File or Volume class (see Section 5.4 and Section 5.10).
  • Volumes mounted foreign (/FOREIGN)
    Virtual read and write functions are converted to logical I/O. All other functions are not processed by the operating system and are sent to the device driver for processing. Physical I/O functions also require PHY_IO privilege.
  • Devices without a mounted volume
    Access to devices without mounted volumes requires privilege.
• $QIO to devices that are not file-oriented
  With non-file-oriented devices, OpenVMS converts virtual read and write I/O requests to logical I/O before processing them. Other kinds of access requests are not processed by OpenVMS; instead, the request is passed to the device driver for processing.
  In general, access requirements for devices that are not file oriented depend on whether the device is shareable or nonshareable:
  • Shareable devices
    With shareable devices, such as mailboxes, any virtual I/O function other than READVBLK/WRITEVBLK is handled by the system I/O driver program. Any logical I/O function requires privilege or logical access to the device. Any physical I/O function requires privilege or physical access to the device.
  • Unshareable devices
    With unshareable devices, such as terminals or printers, the operating system checks only for read or write access to perform virtual and logical I/O functions. Any physical I/O function requires privilege.

Table 5-1 show the access requirements for devices that are not file oriented.

Table 5-1 Access Requirements for Non-File-Oriented Devices

Functions Requiring Read Access
READHEAD	READVBLK	TTYREADALL
READPBLK	REREADN	TTYREADPALL
READLBLK	REREADP
READTRACKD	READPROMPT
Functions Requiring Write Access
WRITECHECK	WRITELBLK	WRITETRACKD
WRITECHECKH	WRITEPBLK	WRITEVBLK
WRITEHEAD	WRITERET

5.3.4 Template Profile

The device class provides the following template profiles:

Template Name	Device Type	Owner UIC	Protection Code
BUS	DC$_BUS	[SYSTEM]	S:RWPL,O:RWPL,G,W
CARDREADER	DC$_CARD	[SYSTEM]	S:RWPL,O:RWPL,G,W
COMMUNICATION	DC$_SCOM	[SYSTEM]	S:RWPL,O:RWPL,G,W
DEFAULT		[SYSTEM]	S:RWPL,O:RWPL,G:RWPL,W:RWPL
DISK	DC$_DISK	[SYSTEM]	S:RWPL,O:RWPL,G:R,W
MAILBOX	DC$_MAILBOX	[SYSTEM]	S:RWPL,O:RWPL,G:RWPL,W:RWPL
PRINTER	DC$_LP	[SYSTEM]	S:RWPL,O:RWPL,G,W
REALTIME	DC$_REALTIME	[SYSTEM]	S:RWPL,O:RWPL,G:RWPL,W:RWPL
TAPE	DC$_TAPE	[SYSTEM]	S:RWPL,O:RWPL,G:R,W
TERMINAL	DC$_TERM	[SYSTEM]	S:RWPL,O:RWPL,G,W
WORKSTATION	DC$_WORKSTATION	[SYSTEM]	S:RWPL,O:RWPL,G:RWPL,W:RWPL

5.3.5 Setting Up Profiles for New Devices

A device usually derives its security profile from the template profile associated with its device type; however, the template is often modified. The following list describes how the operating system assigns a profile to different types of devices:

• Devices created during system configuration
  Devices introduced during system configuration with the system commands CONNECT and LOAD (for example, pseudodevices and workstations) take their profiles from the template appropriate for the device type.
• Disks and tapes
  Disk or tape devices take their profile from the DISK or TAPE template profile, respectively. Once the device is visible within a cluster, its profile, with any modifications, is retained across system restarts. Changes to the DISK or TAPE template profile after a device has its security profile do not apply to that device; therefore, it is necessary to reset the specific object profile by using the DCL command SET SECURITY (see Section 4.2.4).
• Devices cloned from template devices
  Devices cloned from template devices (for example, Ethernet devices) assume the security profile of the template device from which they are cloned. Template devices are loaded during the autoconfiguration process; at this time, their profile is taken from the profile template appropriate for the device.
• Mailboxes
  Mailbox devices assume a modified version of the MAILBOX template profile. The system modifies the template so the UIC of the creating process becomes the owner and the protection code is set to the value of the promsk argument to the Create Mailbox ($CREMBX) system service (provided the value is nonzero).
  To maintain compatibility with earlier versions of the operating system, the MAILBOX template has a protection code of 0 (allowing all access). Some applications may need a more restrictive default than the template provides. If you do choose to restrict mailbox access, be aware that the more restrictive access can cause applications to fail in ways that are difficult to diagnose.
• Terminals
  Terminal devices assume a modified version of the TERMINAL template profile. When a user logs in on a terminal, the operating system modifies the profile so the owner becomes the UIC of the process logging in to the terminal. The original security profile for the terminal is restored when the user logs out.

All logical or physical I/O to a spooled device requires privilege.

The LOG_IO privilege allows the user's process to execute the Queue I/O Request ($QIO) system service to perform logical-level I/O operations. LOG_IO privilege is also required for certain device-control functions, such as setting permanent terminal elements.

The PHY_IO privilege allows the user's process to execute the Queue I/O Request ($QIO) system service to perform physical-level I/O operations. The PHY_IO privilege also grants LOG_IO privilege.

To create a permanent mailbox or mark it for deletion requires PRMMBX privilege.

5.3.7 Kinds of Auditing Performed

The following types of events can be audited, provided the security administrator enables auditing for the appropriate event class:

Event Audited	When Audit Occurs
Access	For nonshareable devices, when the process calls $ASSIGN. For a shareable device, when the process calls $QIO.
Creation	When a process creates a virtual device like a mailbox.
Deletion	When a process deletes a virtual device like a mailbox.

	privacy and legal statement
6346PRO_009.HTML