What does the CHECK_PROC_OWNER RACF Callable Service do?

Document ID : KB000043682
Last Modified Date : 10/07/2018
Show Technical Document Details
Introduction:

Question:

What does the CHECK_PROC_OWNER RACF Callable Service do?

Answer:

CHECK_PROC_OWNER checks to see if the calling process is the owner of a
process being called. This is done in a few ways:

1) the user is superuser
2) the user's UID is same as PROCESS' real or saved UID
3) the user has access to resource SUPERUSER.PROCESS.KILL or
SUPERUSER.PROCESS.GETPSENT - depending on call being made - in the
UNIXPRIV resource class.

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).

Basically, the ck_process_owner call is trying to determine if the user is a
superuser or has access to UNIXPRIV(SUPERUSER.PROCESS.GETPSENT). It's not
really a violation. Its just trying to determine something. You may have
gotten this in the past but not have noticed it.

In this case the resource the acid does not have access to is
UNIXPRIV(SUPERUSER.PROCESS.GETPSENT).
If you want to permit this to get rid of that event, you can,
but I don't think this needs to be permitted. What is happening is
the check process owner is being done to see if the calling process
is the owner of the process being called. This is up to a 3 step process:
The first is to see if the user is a superuser, which in this case it is not,
so the second check is done.
The second check is to see if the user's UID is same as the PROCESS' real or
saved UID, which in this case it isn't, so the third check is done.
The third check is an authorization check based on the request type.
In this case the request type is 3 (determined from the line:
Signal code : Signal n/a for type 3 (getpsent) requests
in the TSSOERPT event), so the check is done for
UNIXPRIV(SUPERUSER.PROCESS.GETPSENT). If this check is successful,
the caller is treated as a superuser.

 

 

Instructions:
Please Update This Required Field