Document revision date: 15 July 2002

Events triggering an audit or alarm can include the following:

Example of Events Initiating Security Audits or Alarms
Installation of images Certain types of file access Volume mounts and dismounts	Modifications to system and user passwords, system authorization file, network proxy file, or rights database
Access event requested by an ACL file or global section	Logins, logouts, login failures, break-in attempts

In the following example, assume you decide to audit the file CONFIDREVIEW.MEM. If user ABADGUY accesses CONFIDREVIEW.MEM and has delete access, the following audit record is written to the system security audit log file.

%%%%%%%%%%% OPCOM 11-DEC-1999 09:21:11.10 %%%%%%%%%%% Message from user AUDIT$SERVER on BOSTON Security audit (SECURITY) on BOSTON, system id: 19424 Auditable event: Attempted file access Event time: 11-DEC-1999 09:21:10.84 PID: 23E00231 Username: ABADGUY Image name: BOSTON$DUA0:[SYS0.SYSCOMMON.][SYSEXE]DELETE.EXE Object name: _BOSTON$DUA1:[RWOODS]CONFIDREVIEW.MEM;1 Object type: file Access requested: DELETE Status: %SYSTEM-S-NORMAL, normal successful completion Privileges used: SYSPRV

The auditing message reveals the name of the perpetrator, the method of access (successful deletion accomplished by using the program [SYSEXE]DELETE.EXE), time of access (9:21 A.M.), and the use of a privilege (SYSPRV) to gain access to the file. With this information, the security administrator can take action.

10.6.3 Security Audit Log Files

Security audit messages are written to the security audit log file every time any file is accessed and meets the conditions specified in the audit entry of the ACL for that file (see Section 10.6.4). Access to the file CONFIDREVIEW.MEM, as well as access to any file on the system that is protected with security auditing, prompts an audit record to be written to the security audit log file.

After auditing has been introduced, check with your security administrator periodically to see if any additional break-ins have occurred.

10.6.4 Adding ACEs to Sensitive Files

If you have key files that might have been accessed improperly, you might want to develop a strategy with your security administrator to audit access to the files.

Once you review the situation and ensure that you have done everything possible to protect your files with standard protection codes and general ACLs (described in the OpenVMS Guide to System Security), you may conclude that security auditing is required.

To specify security auditing, you can add special access control entries (ACEs) to files you own or to which you have control access. Keep in mind, however, that the audit log file is a systemwide mechanism, so Compaq recommends that a site security administrator control the use of file auditing. Although you can add auditing ACEs to files over which you have control, the security administrator has to enable auditing of files on a system level.

If you suspect break-in attempts to your account, the security administrator may temporarily enable auditing for all file access. The security administrator can also enable auditing to monitor read access to your files to catch file browsers.

An access violation of one file frequently indicates access problems with other files. Therefore, the security administrator may need to monitor access to all key files having security-auditing ACEs. When undesired access is gained to key files, the security administrator must take immediate action.

In the following example, user RWOODS and his security administrator concur that they must know when a highly confidential file, CONFIDREVIEW.MEM, is being accessed, so RWOODS adds an entry to the existing ACL for the file CONFIDREVIEW.MEM:

$ SET SECURITY/ACL=(ALARM=SECURITY,ACCESS=READ+WRITE- _$ +DELETE+CONTROL+FAILURE+SUCCESS) CONFIDREVIEW.MEM

A logical name can be used in place of another name to represent system objects such as files, directories, devices, or queues. For example, you might assign a logical name to your default disk and directory. Logical names serve two main functions: they increase readability and file independence.

You can define commonly used files, directories, and devices with short, meaningful logical names. Such names are easier to remember and type than the full file specifications. You can define names that you use frequently in your login command procedure. A system manager can define names that people use frequently in the system startup command procedure.

You can use logical names to keep your programs and command procedures independent of physical file specifications. For example, if a command procedure references the logical name ACCOUNTS, you can equate ACCOUNTS to any file on any disk. This chapter includes information about the following:

• Logical name characteristics
• Using system-defined logical names
• Creating logical names
• Deleting logical names
• Logical name translation
• Displaying logical names
• Creating and using search lists
• Logical name table characteristics
• Default logical name tables
• Creating logical name tables
• Modifying the order of logical name translations
• Deleting logical name tables
• Process-permanent logical names

For additional information about the commands described in this chapter, refer to the OpenVMS DCL Dictionary or online help.

11.1 Logical Name Characteristics

Logical names have the following characteristics:

• Are equated to strings (called equivalence strings or equivalence names) or a list of equivalence strings (called search lists). When you use a logical name, the equivalence string is substituted for the logical name.
• Are stored in default logical name tables or logical name tables that you create.
• Can be shorthand for long file specifications.
• Can be defined by you or by the system.
• Can be used to keep programs and command procedures independent of physical file specifications. For example, if a command procedure references the logical name ACCOUNTS, you can equate ACCOUNTS to any file on any disk before executing the command procedure.

In general, when a command accepts a system object, the command checks whether the name you provide is a logical name. If the name is a logical name, the system replaces the logical name with its actual value and executes the command.

In the following example, the logical name COMS is created to represent the directory DISK7:[WALSH.COMMAND_PROC]:

$ DEFINE COMS DISK7:[WALSH.COMMAND_PROC]

The logical name COMS can then be used in DCL commands, as shown in the following examples:

$ SET DEFAULT COMS

$ TYPE COMS:PAYROLL.COM

11.2 Using System-Defined Logical Names

The system creates a set of systemwide logical names for you when you start the system and log in. These logical names allow you to refer to commonly used files or devices without using their physical device names. For a list of these names, see Section 11.9.3.

Every time you log in, the system creates a group of logical names for your process and places these names in your process table. For a list of these names, see Section 11.9.1.

To list your operating system's programs, you do not need to know the name of the disk and directory where these programs are stored. Instead, you can use the logical name SYS$SYSTEM, as follows:

$ DIRECTORY SYS$SYSTEM

The logical name SYS$LOGIN refers to your default device and directory when you log in. If you have changed your current defaults by using the SET DEFAULT command, you can use the following command to display a file from your initial default directory:

$ TYPE SYS$LOGIN:DAILY_NOTES.DAT

11.3 Creating Logical Names

You can create logical names with either the DEFINE command or the ASSIGN command. In this chapter, the DEFINE command is used in the examples.

In general, you create logical names in your process table. Usually, you define logical names in a login command procedure (LOGIN.COM) so you can use the logical name each time you log in. You can also create logical names interactively. However, you can use these logical names only while your current process is active.

The logical names you create in your process table are not available to other users' processes. The system manager or another privileged user can create names in shareable tables, which are accessible to other users. Group and system tables are examples of shareable tables.

For more information about shareable tables, see Section 11.9.4.

11.3.1 Using the DEFINE Command

The format for defining a logical name with the DEFINE command is as follows:

DEFINE logical-name equivalence-string[,...]

You can use the same format to create logical names for node names, file specifications, device names, application-specific information, or for other logical names.

By default, the DEFINE command places logical names in your process logical name table (see Section 11.8), where the logical name is available only to your process and subprocesses. If you want to add logical names to a different logical name table, you can specify a different table with one of the following qualifiers: /JOB, /GROUP, /SYSTEM, or /TABLE=table_name. The first three qualifiers specify the default job, group, and system logical names tables, respectively. The /TABLE=table_name can be used to specify any type of table and is the only qualifier to use when specifying a clusterwide table.

In the following example, the command creates the logical name WORKFILE and equates it to the equivalence string DISK2:[WALSH.REPORTS]WORK_SUMMARY.DAT:

$ DEFINE WORKFILE DISK2:[WALSH.REPORTS]WORK_SUMMARY.DAT

After you define WORKFILE as a logical name, you can use the logical name interchangeably with the equivalence string.

In the next example, the command creates the logical name MY_Q for the print queue BLDGC_LPS20_ANSI:

$ DEFINE MY_Q BLDGC_LPS20_ANSI

You could then use the following command to print the file FABLES.TXT to the BLDGC_LPS20_ANSI print queue:

$ PRINT/QUEUE=MY_Q FABLES.TXT

The next example shows the use of the /TABLE=table_name qualifier to create a logical name in a table other than the process logical name table. By specifying LNM$SYSCLUSTER, the logical name is placed in the default clusterwide table, LNM$SYSCLUSTER_TABLE, and is therefore accessible to every user on the cluster.

$ DEFINE/TABLE=LNM$SYSCLUSTER CUSTOMERS DISK1:[CUSTOMER_VISITS]CUSTOMERS.TXT

11.3.2 Creating Logical Names in Command Procedures for File I/O

You can use logical names in command procedures to perform file I/O (input and output). When you open a file with the OPEN command, you can also create a logical name for the file. Subsequent READ, WRITE, and CLOSE commands can use the logical name instead of the actual file specification to refer to the file.

In the following example, the OPEN command creates the logical name INFILE and the CLOSE command deletes it:

$ OPEN INFILE DISK3:[WALSH]DATA.DAT $ READ INFILE RECORD $ CLOSE INFILE

11.3.3 Rules for Creating Logical Names

Observe the following rules when you create a logical name with the DEFINE command:

• Limit the equivalence string and the logical name to no more than 255 characters each. A logical name can contain alphanumeric characters, the underscore (_), the dollar sign ($), and the hyphen (-).
• When you specify an equivalence string, include the punctuation marks (colons, brackets, periods) required by a file specification. For example, end a device name with a colon, enclose a directory specification in brackets, and precede a file type with a period.
• If a logical name represents only part of a file specification, separate the name from the rest of the file specification with a colon. When you use a logical name to represent a complete file specification, the terminating colon is not needed.
  In addition, be sure the logical name is the leftmost component of a file specification.
• Optionally, end the logical name with a colon.
  Note that the ASSIGN command removes the colon before placing the logical name in a logical name table; the DEFINE command saves the colon as part of the logical name.
• If you equate a logical name to one equivalence string, then equate the same logical name to a different equivalence string. The second definition will supersede the first, unless you define them in different logical name tables or define them with different access modes.

The following commands display the file DISK1:[SALES_STAFF]PAYROLL.DAT:

$ DEFINE PAY DISK1:[SALES_STAFF]PAYROLL.DAT $ TYPE PAY

$ DEFINE PAY_FILE DISK1:[SALES_STAFF]PAYROLL $ TYPE PAY_FILE:*.DAT

$ DEFINE PAY_DIR DISK1:[SALES_STAFF] $ TYPE PAY_DIR:PAYROLL.DAT

$ DEFINE PAY_DISK DISK1: $ TYPE PAY_DISK:[SALES_STAFF]PAYROLL.DAT

11.3.4 Translation Attributes

When you create a logical name, you can specify translation attributes that modify how the system interprets the equivalence string.

To apply translation attributes to an equivalence string, use the /TRANSLATION_ATTRIBUTES qualifier to the DEFINE command. This is a positional qualifier. Depending on where you place it on a command line, it can apply translation attributes to all equivalence strings or only to certain ones.

In the following example, the device name DJA3: is concealed with the logical name DISK:

$ DEFINE/TRANSLATION_ATTRIBUTES=CONCEALED DISK DJA3: $ SHOW DEFAULT DISK:[SAM.PUP] $ SHOW LOGICAL DISK "DISK" = "DJA3" (LNM$PROCESS_TABLE)

The logical name DISK represents the physical device DJA3. Thus, the SHOW DEFAULT command displays the logical name DISK rather than the physical device name DJA3. The SHOW LOGICAL command reveals the translation of DISK.

The CONCEALED attribute causes system messages to display the logical name rather than the physical name of a device. Typically, you use the CONCEALED attribute with logical names that represent physical devices. Using concealed devices lets you write programs, write command procedures, and perform other operations without being concerned about which physical device holds the disk or tape. It also lets you use names that are more meaningful than the physical device names.

The TERMINAL attribute prevents iterative translation of a logical name (that is, the equivalence string is not examined to see whether it is also a logical name). The translation is "terminal" (final or completed) after the first translation.

11.3.5 Access Modes

The OpenVMS operating system has the following four access modes:

• User mode (the outermost and least privileged mode)
• Supervisor mode
• Executive mode
• Kernel mode (the innermost and most privileged mode)

You can use the DCL commands DEFINE or ASSIGN to create logical names in the first three modes (user, supervisor, and executive). By specifying different access modes for each logical name definition, you can equate the same logical name to different equivalence strings in the same logical name table. Note that you must have SYSNAM or SYSPRV privileges to create logical names in executive mode in any logical name table.

User Mode

Logical names created in user mode are temporary. Define a logical name in user mode when you want to use it only for the execution of the next command or image.

In the following example, the logical name ADDRESSES is deleted automatically after the execution of the program PAYABLE:

$ DEFINE/USER_MODE ADDRESSES DISK1:[SAM.ACCOUNTS]OVERDUE.LIS $ RUN PAYABLE

Supervisor Mode

When you use the DEFINE command without specifying a mode, DCL creates the logical name in supervisor mode.

In the following example, the commands equate the logical name ACCOUNTS to two different equivalence strings in the process logical name table---one in supervisor mode and one in executive mode:

$ DEFINE ACCOUNTS DISK1:[ACCOUNTS]CURRENT.DAT $ DEFINE/EXECUTIVE_MODE ACCOUNTS DISK1:[JANE.ACCOUNTS]OBSOLETE.DAT

Executive Mode

In looking up logical names, all privileged images and utilities such as LOGINOUT bypass the user mode and supervisor mode names and tables. If a logical name is to be used by a privileged image, including a utility, it must be defined in executive or kernel mode in an executive or kernel mode table. Other candidates for logical names defined in executive mode are the names of public directories used by your work group and system resources, such as print queues and system disks.

Kernel Mode

Only the operating system and privileged programs can create logical names in kernel mode.

11.3.6 Creating Logical Node Names

You can use a logical node name in place of a network node name or in place of a node name and an access control string. Once you define a logical node name, you can use it to avoid typing (and displaying) your user name and password on the screen.

To define a logical node name, observe the following rules:

• Do not begin the logical name with an underscore (_).
• End the equivalence string with a double colon (::) and enclose it in quotation marks (" ").
• Use two sets of quotation marks ("" "") where you want quotation marks to appear in the access control string.
  (For information about access control strings, see Section 3.1.6, Section 3.1.12, and Section 10.5 in this manual.)
• Specify a logical name that contains 1 to 255 characters.

In the following example, the command equates the logical name BOS to the node name BOSTON and an access control string, where ADAMS is the user name and OLMEKIKA is the password:

$ DEFINE BOS "BOSTON""ADAMS OLMEKIKA""::"

11.3.6.1 Using Logical Node Names in File Specifications

A file specification can contain both a logical node name (which the system translates at the local node) and a logical device name (which the system translates at the remote node). If you use a logical name to represent a node name only, you must include a double colon (::) when you use the logical name in the node position of a file specification.

After the system translates a logical node name at the local node, it parses the rest of the file specification to determine whether the format is valid.

In the following example, the system translates the logical node name NYC at the local node. It translates the logical device name (DOC:) at the remote node (NEWYRK):

$ DEFINE NYC NEWYRK:: $ TYPE NYC::DOC:[PERKINS]TERM_PAPER.DAT

11.3.6.2 Overriding Access Control Strings

To override the access control string in a logical node name, specify both the logical name and an access control string in the command line.

In the following example, the access control string "REVERE HTEBAZILE" overrides the access control string given in the equivalence string for BOS:

$ DEFINE BOS "BOSTON""ADAMS OLMEKIKA""::" $ TYPE BOS"REVERE HTEBAZILE"::RIDE.DAT

When the system translates a logical node name iteratively, the access control information in the logical node name that is first translated overrides the following access control information. For example, the logical name TEST1 translates to TORONTO"TEST NAMWENLUAP"::DBA1: :

$ DEFINE TORONTO "TRNTO""TEST EIZNEKCAM""::" $ DEFINE TEST1 "TORONTO""TEST NAMWENLUAP""::DBA1:" $ TYPE TEST1:PROC.DAT

TORONTO is a logical node name, so iterative translation occurs. In other words, the operating system searches the logical name tables until all levels of logical names in a definition are found. However, the access control string in the DEFINE TEST1 logical name assignment overrides the access control string in the DEFINE TORONTO logical node name assignment. Therefore, the TYPE command displays the following file:

TRNTO"TEST NAMWENLUAP"::DBA1:PROC.DAT

	privacy and legal statement
6489PRO_026.HTML