How To Interpret The 8/8:4 Return Codes From OMVS Traces?

Products

• Cleanup
• Datacom
• DATACOM - AD
• CIS
• COMMON SERVICES FOR Z/OS
• 90S SERVICES
• DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS
• COMMON PRODUCT SERVICES COMPONENT
• Common Services
• CA ECOMETER SERVER COMPONENT FOC
• Easytrieve Report Generator for Common Services
• INFOCAI MAINTENANCE
• IPC
• UNICENTER JCLCHECK COMMON COMPONENT
• Mainframe VM Product Manager
• CHORUS SOFTWARE MANAGER
• CA ON DEMAND PORTAL
• CA Service Desk Manager - Unified Self Service
• PAM CLIENT FOR LINUX ON MAINFRAME
• MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME
• GRAPHICAL MANAGEMENT INTERFACE
• WEB ADMINISTRATOR FOR TOP SECRET
• Xpertware
• Top Secret
• Top Secret - LDAP
• Top Secret - VSE

Issue/Introduction

Description:

From time to time, users receive 8/8:4 from the following callable services:

ck_process_owner

ck_access

How do we interpret them?

Solution:

First of all, the return codes format; 8/8:4 are respectively;

• The SAF return code,
• The RC return code for the callable service
• The RSN which is the reason.

The SAF/RC:RSN 8/8:4 on ck_process_owner really means the caller is not the owner of the process as specified on the call.

The reason why the explanation is put as failing authorization for the callable service is that a superuser is always given

return codes indicating that the caller is the owner, and the service is usually invoked by a superuser.

But the technical meaning of the return codes is that the caller does not own the process being checked.

For this call, the caller is considered a superuser if the uid (either the current or the real uid) is 0 or if the user has access to

UNIXPRIV(SUPERUSER.PROCESS.GETPSENT)

The SAF/RC/RSN 8/8:4 on a ck_access simply means if caller is not UID 0 and is seeking an access only allowed

to the file owner.

    SERVICE      USERID    GROUP        UID         GID    SAF  RC   RSN
      DATE       TIME      JOBNAME      SOURCE      SYSID  CPU   SECLABEL   

Auditor : Read None Write None Exec/Search None
Effective UID: 5555 Effective GID: 55555
ck_access MYACID MYGRP 5555 55555 8 8 4
01/26/13 13.026 9.12.57 MYJOBNAME SYST
Failed - User not authorized to access file
Function: open User Type: Local
Requested Access: Read/Write
Name flag: Use CRED_name_flag to determine pathname
Pathname: /allapplication/myapplication/myfile.app
Filename: myfile.app
File Permissions: Owner: rw- Group: r-- Other: r--
Owning UID: 1000 Owning GID: 1000000000
Volume : File Identifier: 2E0000000000000000
File Audit Options:
User : Read Failure Write Failure Exec/Search Failure
Auditor : Read None Write None Exec/Search None
Effective UID: 5555 Effective GID: 55555

In the example above, MYACID:

• Hasn't got UID 0.
• Is not the owner of the file (myfile.app).
• Is not in the right group (GID 1000000000).

then only Other authorization will apply where read is allowed.

User asks for Read/Write, so access is denied accordingly.

Environment

Release: TOPSEC00200-15-Top Secret-Security
Component: