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

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

book

Article ID: 129858

calendar_today

Updated On:

Products

ACF2 ACF2 - DB2 Option ACF2 for zVM ACF2 - z/OS 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     777777     888888     8      8     4 
     03/21/19  19.080 7.15.33 LIBJOB     SYSX     SYSX 
Failed - The user is not authorized to access the IPC mechanism 

Access code: Read access 

Function: semctl 
IPC key from CR 999999999
 

IPC ID from CRE 9999 

User Type: Local 

IPC key from II 9999999999 
IPC ID from IIS 9999 
Owner eff UID: 8888 Owner eff GID: 5200 
Create eff UID: 8888 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 777777 and GID 888888 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).