Can CAS9RACL cause possible system integrity problems using ICHAUTAB?

Products

• COMMON SERVICES FOR Z/OS

Issue/Introduction

In the Common Services r15.0 documentation detailing the installation of CAS9RACL for CICS/TS it states: 
  Add the programs DFHSIP, CAS9LRAC, and CAS9RACL to the RACF-authorized caller table, ICHAUTAB, for RACLIST right only.
  Define the CAS9LRAC program to the current startup and shutdown PLT for CICS using the following entry
  DFHPLT TYPE=ENTRY,PROGRAM=CAS9LRAC

However, IBM recommends that this method not be used:
  Incorrect use of ICHAUTAB can cause system integrity problems, do not use it; instead run these programs with APF-authorization

What is the right way to resolve this inconsistency ? 

 

Environment

Release : 15.0

Component : CAIENF/CICS

Cause

The IBM documentation also states that the problem can be caused if RACROUTE=LIST or VERIFY is not used with the entries being added to ICHAUTAB..      

Resolution

CAS9LRAC must reside in the DFHRPL concatenation and gets invoked through the startup PLT so it won’t be APF authorized unless the rest of the RPL is which is something clients will not do. CAS9LRAC does a LINK to CAS9RACL which does the RACROUTE=LIST, a VERIFY is NOT done out of this code. The only way to provide the authorization in this way is to utilize ICHAUTAB. The RACROUTE LIST you see in CAS9SAFC is not for CICS (this is why we have CAS9LRAC/RACL), it is for authorized users issuing a #SECUR macro for resources that have the FASTAUTH=YES in the CAS9RACF table. If a resource has CICS=YES in the CAS9RACF table, it will be RACLIST’d by CAS9LRAC/RACL at CICS initialization time.

 

Additional Information

Refer to the reference to ICHAUTAB in the IBM RACF System Programmer's Guide 
Install CAS9RACL as detailed in the Common Servics r15.0 documentation