SYS$MANAGER:SYLOGIN.COM - Verification of SYLOGIN Processing Without Disruption

OpenVMS LOGINOUT and CLI initialization provide a powerful tool for customizing individual OpenVMS sessions. However, this power is not without hazard. Errors in customization can easily lead to inappropriate process contexts, which can lead to software failures and disruptions of system availability. Establishing a framework for fault isolation and diagnosis greatly reduces these risks. The general concepts, principles, and dangers of modifying files executed as part of initial process creation are the subject of a previous installment of this column (see SYS$MANAGER:SYLOGIN.COM: Flexibility Requires Prudence). It is temptingly simple to insert a SET VERIFY as the first line in of the command file automatically invoked during CLI initialization (for DCL, SYS$MANAGER:SYLOGIN.COM; hereafter, SYLOGIN). It is certainly effective. However, a globally effective SET VERIFY is an extremely crude bludgeon. On an individual workstation or virtual system, it may seem reasonable, until the realization sinks in that even in so simple an environment, SYLOGIN is used by far more processes than is at first obvious. Most process creations are of little interest in debugging the problem at hand. The overhead incurred in creating the resulting line-by-line DCL logs can produce delays that cause other software to fail, resulting in an unstable or unusable system. Precise control of when SET VERIFY is executed is crucial to creating a usable, stable, debugging environment with minimal collateral damage. A careful look at the precise process context already established when control is transferred to SYLOGIN will show how we can control enabling DCL verification with a high degree of precision. When LOGINOUT.EXE invokes the CLI at its initialization entry point, which then invokes SYLOGLIN, the underlying process state is:

the command language interpreter (CLI) specified by the CLI parameter in the SYSUAF, most commonly DCL, has been established. This is the most common case, namely SYLOGIN is SYS$MANAGER:SYLOGIN (determined from the translation of system logical name SYS$LOGIN [verify with IDSM]. Generally, the logical name omits the file type, allowing the logical name to be used by multiple CLIs (e.g., DCL and MCR). Which file is actually invoked is then governed by the individual CLI (DCL uses a default file type of .COM) therefore generally invoking SYS$MANAGER:SYLOGIN.COM
the process' CLI table is set to the value specified in the corresponding system authorization file entry.
By implication, the search list for logical name translation (LNM$FILE_DEV in LNM$DIRECTORY) is defaulted to the LNM$FILE_DEV in the system-wide directory (LNM$SYSTEM_DIRECTORY)
The process is executing under the user’s UIC and username; with quotas and privileges as specified in the current authorization file (or the system’s minimums, specified in the system parameter file; whichever is controlling)

The user's login command file is after the system wide login is invoked using the contents of the LGICMD field, with defaults supplied by the DEVICE and DIRECTORY parameters. This basic process context provides a good context to manage many aspects of the process, including the DCL verification flag. There are a multitude of possibilities for limiting the scope of the SET VERIFY. One could use the username or UIC to explicitly control the use of SET VERIFY. This would, however, be a very crude tool, requiring constant changes to SYLOGIN. The rights list identifiers and other existing process context present far more fertile opportunities.. As an aid to understanding, three sample command files implementing different techniques for selectively enabling DCL verification have been posted to my firm’s demonstration area at http://www.rlgsc.com/demonstrations/login-dcl-trace.html. For safety, each of the sample files can be invoked from the beginning of an individual’s LOGIN.COM, rather than inserting the code segment into the system-wide SYLOGIN Thus, the samples can be tested without system-wide impact. DCLTRACE_RIGHTSLIST.COM illustrates a simple example of a rights list-based implementation. As a simple example of what can be done, consider how SYLOGIN can be modified to use a rights list identifier to control SYLOGIN processing for interactive processes. Rather than forcing all user sessions to log each DCL command, DCL verification can now be enabled for a single user’s interactive sessions, a change with far less impact. The privileges to create a rights list identifier and grant it to an individual user will be required.

...
$ RIGHTSLIST = "," + F$GETJPI("", "RIGHTSLIST") + ","
$ IF F$LOCATE(",TRACE_LOGIN,", RIGHTSLIST) .NE. F$LENGTH(RIGHTSLIST)
$ THEN<\br/> $ SET VERIFY
$ ENDIF
...

The benefit to using rights list identifiers is that rights list identifiers are stored in the system rights list, generally shared across the nodes of an OpenVMS cluster and persists across system restarts.

The Achilles heel of the rights list-based approach is the granting and revocation of the TRACE_LOGIN identifier. Rights list operations (ADD/GRANT/REVOKE in AUTHORIZE) require privileged access to the system authorization file and rights list. Such access is often a problem. Granting the required privileges compromises the system security posture. Requiring system manager intervention to enable or disable DCL verification increases the system managers' workload and can lead to delays.

It would be useful if such a facility could be enabled and disabled by an individual programmer or project manager without danger to other users, certainly without requiring intervention by the system manager.

The contents of the Group logical name table can also be used to control DCL verification. This alternate approach has different strengths and weaknesses from the rights list-based approach. The Group logical name table is a less global resource, and the required GRPNAM (Group Logical Name) privilege has less potential for interrupting system operation than SYSPRV or similar privileges required to add, grant, and revoke rights list identifiers. The drawback to this approach is that the group logical name table is local to a specific node of an OpenVMS cluster, and is also not preserved across system restarts (however, a combination of boot-time command files and the SYSMAN DO command can somewhat ameliorate this limitation). Within these limitations, this approach is also quite effective. DCLTRACE_GROUP.COM checks for logical name TRACE_LOGIN in the logical name search path, which by default is includes both the System and Group logical name tables. If the logical name is present, and it has a string value of “TRUE” , DCL verification will be enabled.

The advantage of logical name approach is a reduction in the level of privilege required to enable DCL logging during process creation. Any user permitted to modify the group logical name table can now enable/disable DCL logging for their group, once the underlying code has been included in SYLOGIN. However, DCLTRACE_GROUP.COM remains less than precise; it controls DCL login verification for an entire group. A related example, DCLTRACE_USERWITHINGROUP.COM combines the flexibility of group logical names with per-username precision. Users with GRPNAM privilege can define or modify a list of usernames whose process creations are to be traced. Enabling or disabling DCL tracing is merely a question of inserting or removing a username from the list.

Admittedly, DCLTRACE_USERWITHINGROUP.COM is a simple example. One could easily use it as a starting point for a far more easily managed facility. For example, one could implement a command file to insert and remove usernames from the TRACE_LOGIN group logical name. DCL verification during the login process is a powerful tool. A modicum of forethought permits this tool to be made available to a wide range of users and developers, without risk to overall system operation or security.

URLs for referencing this entry

Long:	http://www.rlgsc.com/blog/openvms-consultant/sylogin-verification.html
Short:	http://rlgsc.com/r/20100711.html