Jane.doe at 08:47, 3 February 2020

2020-02-03T08:47:08Z

← Older revision		Revision as of 08:47, 3 February 2020
Line 3:		Line 3:
	=Naming rules=		=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. See [[Device ~~name~~]] for more information.		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. See [[Device Name]] for more information.

	=Types of access=		=Types of access=

Darya.zelenina at 10:32, 2 March 2019

2019-03-02T10:32:40Z

← Older revision		Revision as of 10:32, 2 March 2019
Line 43:		Line 43:
	==$QIO to file-oriented devices: disks and tapes==		==$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.		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:		Beyond this, access requirements depend on how the volume is mounted:

Darya.zelenina at 08:32, 19 December 2018

2018-12-19T08:32:38Z

← Older revision		Revision as of 08:32, 19 December 2018
Line 3:		Line 3:
	=Naming rules=		=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. See [[Device ~~names~~]] for more information.		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. See [[Device name]] for more information.

	=Types of access=		=Types of access=

Darya.zelenina: Created page with "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..."

2018-08-23T06:15:39Z

Created page with "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..."

New page

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|disk]] or [[Terminal|terminal]], or it can be virtual, like a [[Mailbox|mailbox]] or [[Pseudoterminal|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 system.

=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. See [[Device names]] for more information.

=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:

{| class="wikitable"
|-
| 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.

=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 “Files” and “Volumes”).

===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.

=Template profile=

The device class provides the following template profiles:

{| class="wikitable"
|-
! 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,W
|-
| 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
|}

=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 “Modifying a Security Profile”).

==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.

'''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:

<pre>$ SET SECURITY/CLASS=DEVICE -
_$ /PROTECTION=(S:RWLP,O:RWLP,G:RW,W:R) FTA0:</pre>

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.

=Privilege requirements=
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.

=Kinds of auditing performed=

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

{| class="wikitable"
|-
! 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
|}

=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.

Device - Revision history

Jane.doe at 08:47, 3 February 2020

Darya.zelenina at 10:32, 2 March 2019

Darya.zelenina at 08:32, 19 December 2018

Darya.zelenina: Created page with "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..."