ck_IPC_access failure with ACF2 starting z/OS Connect EE LIBERTY STC

Products

• CA ACF2
• CA ACF2 - DB2 Option
• CA ACF2 for zVM
• CA ACF2 - z/OS
• CA ACF2 - MISC

Issue/Introduction

IBM’s z/OS Connect Enterprise Edition V3.0 'LIBERTY' started task fails to start, getting ck_IPC_access 'Failed - The user is not authorized to access the IPC mechanism '. How can the ck_IPC_access error be addressed?

ACFRPTOM report shows:

      SERVICE      USERID    GROUP        UID         GID    SAF     RC    RSN 
        DATE          TIME    JOBNAME   SOURCE   SYSID   CPU   SECLABEL        
     ck_IPC_access LIBERTY    LIBRPL     105232     100002     8      8     4 
     03/21/19  19.080 7.15.33 ZCLIBT13   E09Z     E09Z 
Failed - The user is not authorized to access the IPC mechanism 

Access code: Read access 

Function: semctl 
IPC key from CR 2130700985 
IPC ID from CRE 4109 

User Type: Local 

IPC key from II 2130700985 
IPC ID from IIS 4109 
Owner eff UID: 5204 Owner eff GID: 5200 
Create eff UID: 5204 Create eff GID: 5200 

S_IRUSR: Process owning the IPC member can read it 
S_IWUSR: Process owning the IPC member can alter it 
S_IRGRP: Group associated with the IPC member cannot read it 
S_IWGRP: Group associated with the IPC member cannot alter it 
S_IROTH: Others cannot read the IPC member 
S_IWOTH: Others cannot alter the IPC member 

Environment

Release:
Component: ACF2MS

Resolution

The logonid LIBERTY with UID 105232 and GID 100002 is failing the authorization check for access to the interprocess communication (IPC) key or identifier whose IPC security packet (IISP) is passed.

According to IBM ( ck_IPC_access (IRRSKI00): Check IPC access RACF authorization):

The ck_IPC_access access checks performed are XPG4 IPC permission checks defined in XPG4 System Interfaces and Headers, as follows:

• The effective z/OS UNIX user identifier (UID) and z/OS UNIX group  identifier (GID) for the calling process is used for all access checks.
• If the CREI user type is system, IRRSKI00 allows any access. No UIDs or GIDs are used in this case because no process exists.
• If the user being checked is a superuser, IRRSKI00 allows any access. The user is considered a superuser if the selected UID is 0 or if the ACEE indicates trusted or privileged authority.
• If the user is not system and is not a superuser, the permission bits for the IPC key are checked to see if the access requested is allowed. If the effective UID matches either the owner UID or creator's UID of the IPC key, the USER permission bits are checked. If the UIDs do not match, the owner GID and creator's GID of the IPC key are checked against the user's effective GID and the user's supplemental group list GIDs. If any one matches, the GROUP permission bits are checked. If the UIDs and GIDs don't match, the OTHER permission bits are checked.

To address the 'not authorized' condition logonid LIBERTY either needs UID(0), NON-CNCL or give logonid LIBERTY a UID or GID that matches either the owner UID or creator's UID of the IPC key(as mentioned in point 4 above).