Technical data

Adding OSM Process Files to TACLCSTM and CMON Exceptions
A TACLCSTM script which expects direct human interaction will interfere with certain OSM actions
and activities. Some OSM processes start TACLs which are non-interactive, with the user ID of the
OSM Service Connection session, or with the SUPER.SUPER ID for unattended OSM operations.
The most likely issues to be noticed without previous planning occur for a shared service user id.
Issues are also possible for the SUPER.SUPER user ID.
If an interactive script is part of the TACLCSTM file, you must grant exceptions to TACL sessions
that the program files SEEVIEW, CIPPRVD, MDEVPRVD, and EVTL create. These program files
launch TACL sessions on behalf of OSM commands or for unattended background activities.
A customized CMON exerts additional control over TACL processes. In some cases, you will also
need to grant CMON exceptions for TACL processes created by SEEVIEW, CIPPRVD, MDEVPRVD,
and EVTL.
OSM uses the SEEVIEW program file to launch TACL processes for some OSM actions. These
actions include CLIM and Disk Enclosure firmware updates, "Set LED State" for a SAS Disk Enclosure
or CLIM Attached Disk, and CLIM rediscover. If there is a problem caused by an interactive
TACLCSTM, these OSM actions can appear to hang "In Progress" in the OSM user interface. If
you suspect this problem arises from TACLCSTM interactions for a particular user ID, start a new
OSM session with a different user ID and use the "Set LED State" or CLIM rediscover command to
test your suspicions.
OSM also creates TACL processes directly from the program files CIPPRVD, MDEVPRVD, and EVTL
for other activities. For example, MDEVPRVD can start a TACL as SUPER.SUPER to run a
customer-supplied script as part of Power Fail shutdown. This activity occurs in the background
without the possibility of human user interaction. EVTL starts a TACL to automatically configure
Expand line handlers for remote systems added into a ServerNet Cluster.
These TACLCSTM and CMON issues for OSM usually begin as a consequence of improved
security auditing of TACL sessions. User-initiated OSM actions are audited in the
$system.zservice.ztrc* files. There is OSM auditing of user-issued OSM actions invoking
TACL even when exceptions are in place for the usual TACL session auditing.
An engineer from your service provider usually logs on to tools such as the OSM Service Connection
or TACL with a specific NonStop user ID in the SUPER group. Your security group might want to
audit the use of this shared service user ID, or audit the use of the SUPER.SUPER ID. The TACLCSTM
file for one or more user IDs might call an interactive script which verifies the identity of the particular
individual working on the system.
In this example, TACLCSTM for SUPER.SERVICE calls an interactive XYGATE Access Control
(XAC) script named super-service-tacl for direct human use of TACL. Grant a TACLCSTM
exception for OSM as follows:
?tacl macro
== TACLCSTM for SUPER.SERVICE.
#push ancestor programfile
#set ancestor [#lookupprocess /ancestor/ [#processinfo /processid/]]
#set programfile [#processinfo/programfile/ [ancestor]]
== Grant exceptions to TACL processes created for OSM actions and activities.
[#if ([#match *SEEVIEW [programfile]]) or
([#match *CIPPRVD [programfile]]) or
([#match *MDEVPRVD [programfile]]) or
([#match *EVTL [programfile]])
== Add any other special conditions such as a XYGATE terminal already audited.
|then|
== Skip XAC command.
|else|
xac super-service-tacl
== Add any additional processing after XAC.
]
== Add any additional TACLCSTM code.
== Avoid redefining basic TACL behavior, interfering with OSM use of TACL.
14 OSM Server-Based Components