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. Virtual terminals are considered
LOCAL devices. They can be created over the network or on the local
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
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
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 HP OpenVMS System Manager's
Manual and the HP OpenVMS User's Manual for a full description of device names.
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
Gives you the right to
read data from the device
Gives you the right to
write data to the device
Gives you the right to perform physical I/O operations to the
Gives you the right to perform logical I/O operations to the
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
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
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
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
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 “Files” and “Volumes”).
Volumes mounted 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
Access to devices without mounted
volumes requires privilege.
$QIO to devices that are
not 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
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.
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
The device class provides the following template
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
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 “Modifying a Security Profile”).
Devices cloned from template
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.
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.
Terminal devices assume a modified version of the TERMINAL template
NOTE: In OpenVMS Version 7.2-1 and earlier, all pseudo-terminal
(FT) device protection codes were set by the driver to (S:RWLP,O:RWLP,G,W).
In OpenVMS Version 7.3 and later, only device FTA0 is set to this
forced protection. This allows the system manager the option of modifying
the FTA0 device protection later in the boot process. This new protection
is inherited from FTA0 by any new FT devices created thereafter (as
well as other settings originating from the SECURITY class DEVICE
TERMINAL template profile, such as ACLs).
A system manager can modify FTA0 manually, or
change the SYSTARTUP_VMS.COM command procedure. For example:
$ SET SECURITY/CLASS=DEVICE -
_$ /PROTECTION=(S:RWLP,O:RWLP,G:RW,W:R) FTA0:
If the device protection for FTA0 is left unmodified,
the behavior is unchanged from versions of OpenVMS prior to Version
7.3. That behavior is that all terminals except FT pseudo-terminal
devices inherit their device protection and other security characteristics
from the TERMINAL template profile. All FTA pseudo-terminal devices
inherit their protection from FTA0, which by default is set to (S:RWLP,O:RWLP,G,W).
Other settings, such as ACLs, are inherited from the TERMINAL template
profile. This ensures compatibility with existing applications.
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
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
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
To create a permanent mailbox or mark it for deletion
requires PRMMBX privilege.
Kinds of Auditing Performed
The following types of events can be audited,
provided the security administrator enables auditing for the appropriate
When Audit Occurs
For nonshareable devices, when the process calls $ASSIGN; for
a shareable device, when the process calls $QIO
When a process creates a virtual device like a mailbox
process deletes a virtual device like a mailbox
Permanence of the Object
The profile of clusterwide disks and tapes is
stored in the object database VMS$OBJECTS.DAT, but other object profiles
have to be reset each time the system starts up.