Configuring Your Product › Activate the CA Disk System › Activate CA Disk Features › Activate Miscellaneous Security Features › Grant or Deny Access to System-Installed Intercept Modules

Grant or Deny Access to System-Installed Intercept Modules

It may be necessary or desirable to either grant or deny access to modules that are installed as system intercepts. The DMSAR (Auto-Restore function) requires the access to load and activate several modules to install the intercepts that provide the Auto-Restore functions. There are also several tracing modules, which are often used to diagnose CA Disk, you might want to limit access to.

DMSAR requires access to the following modules:

• ADSAR010
• ADSAR026
• ADSHS001
• DIMCH400

There is also an IGGDASU2 exit that may be installed and its name is ADSDASU2. For more information about the purpose of the exit, see Installation of IGGDASU2 User Exit.

Following are the Tracing modules:

• ALLOCTRC
• ATLGTRC
• DYNALLOC
• PROGMTRC
• SCRTHTRC

By defining profiles in your security system and denying or permitting access to those profiles, you can grant or deny access to modules that are installed as system intercepts. The profiles are of the format CSVDYLPA.ADD.modname and CSVDYLPA.DELETE.modname, where modname is either a distinct module name or a module name pattern.

Important! If your installation does not deny access to these resources and you do not need to deny access to the tracing modules, you can skip the rest of this topic.

To grant access to a module name, you need to execute several commands. For DMSAR to work properly, access to several resources must be granted.

Example 1: Deny Access to DIMCH400

These example commands deny access to a module named DIMCH400, based on your security system.

Note: You must have specific authorization to issue these commands.

TOPSECRET Commands:

• TSS ADDTO (deptacid) IBMFAC (CSVDYLPA.ADD.DIMCH400)
• TSS ADDTO (deptacid) IBMFAC (CSVDYLPA.DELETE.DIMCH400)

RACF Commands:

• RDEFINE FACILITY CSVDYLPA.ADD.DIMCH400 +
• UACC (NONE) NOTIFY (security administrator)
• RDEFINE FACILITY CSVDYLPA.DELETE.DIMCH400 +
• UACC (NONE) NOTIFY (security administrator)

Example 2: Grant Access to DIMCH400

These example commands grant access to the DIMCH400 module by userid WXY0005.

TOPSECRET Commands:

• TSS PERMIT (WXY0005) IBMFAC (CSVDYLPA.ADD.DIMCH400) ACC (UPDATE)
• TSS PERMIT (WXY0005) IBMFAC (CSVDYLPA.DELETE.DIMCH400) ACC (UPDATE)

RACF Commands:

• PERMIT CSVDYLPA.ADD.DIMCH400 CLASS (FACILITY) +
• ACCESS (UPDATE) ID (WXY0005)
• PERMIT CSVDYLPA.DELETE.DIMCH400 CLASS (FACILITY) +
• ACCESS (UPDATE) ID (WXY0005)

You can also grant permission to access these FACILTY class resources to a group of people by replacing the userid WXY0005 by a group id or by multiple userids.

Note: It is necessary to perform the previous commands for each module to which you wish to grant or deny access.

Example 3: Define access rules for ACF2:

This example commands define access rules for ACF2:

ACF
Set Resource(FAC)
COMPILE *
$KEY(CSVDYLPA) TYPE(FAC)
ADD.DIMCH400 UID(wxy0005) SERVICE(UPDATE) ALLOW
DELETE.DIMCH400 UID(wxy0005) SERVICE(UPDATE) ALLOW
<enter>
STORE
END

Running this resource definition denies access to all CSVDYLPA resources except for the user WXY0005. User WXY0005 will be able to access CSVDYLPA.ADD.DIMCH400 and CSVDYLPA.DELETE.DIMCH400.

Note: ACF2 is RULE based and all of the rules for a particular $KEY must be included when that $KEY is recompiled. Any rules that are not included will not be retained. The rules can include wildcard characters in the userid and the resource names, and can use identification criteria other than userid. For more information about defining the access rules, see the CA ACF2 documentation and contact your ACF2 administrator.

Note: If the FACILITY resource class is specified as resident in the GSO INFODIR record, any rule changes or additions can be activated by issuing the following operator command:

F ACF2,REBUILD(FAC)