z/OS Security Server RACF Callable Services
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


RACF authorization

z/OS Security Server RACF Callable Services
SA23-2293-00

The authorization requirements differ among the R_admin functions. For the functions which send requests to the RACF® subsystem address space (all of the input functions, and password/password phrase envelope retrieval), a user ID is passed to the RACF address space where an ACEE is created under which to execute the RACF command. For the profile extract functions, which run in the caller's address space, the actual ACEE, if present, will be used for authority checking. If a user ID is provided, an ACEE will be created for this purpose. Only a supervisor state caller can directly specify the user ID or ACEE as a parameter to R_admin. The following list shows the possible sources of the user ID or ACEE, in the order in which they are searched:
  • The RACF_userID parameter (supervisor state callers only)
  • The ACEE_ptr parameter (supervisor state callers only)
  • The user ID associated with the current task control block (TCB)
  • The user ID associated with the current address space (ASXB)

Where appropriate, see the Authorization Required topic for the relevant RACF command, in the z/OS Security Server RACF Command Language Reference.

The following table summarizes the authorization required for the function codes:
Function code Problem state allowed? Command authority enforced? FACILITY class authorization
ADMN_RUN_COMD Yes Yes For problem state callers only, READ access to IRR.RADMIN.command-name. The resource must be defined using the full command name even if the abbreviated version of the command name is used with R_Admin. (For example, 'LU JOEUSER' would require READ authority to IRR.RADMIN.LISTUSER.)
Update function codes (X'01'-X'04' and X'06'- X'15') No Yes N/A
ADMN_XTR_SETR Yes Yes (optionally for a supervisor state caller). The authorization rules of the SETROPTS LIST command are applied. For problem state callers, and for supervisor state callers who request it, READ access to IRR.RADMIN.SETROPTS.LIST
ADMN_UNL_SETR No No N/A
ADMN_XTR_PPENV No N/A READ access to IRR.RADMIN.EXTRACT.PPENV (If this access check is being audited, the logstring will identify the user ID whose password phrase envelope was extracted.)
ADMN_XTR_PWENV No N/A READ access to IRR.RADMIN.EXTRACT.PWENV (If this access check is being audited, the logstring will identify the user ID whose password envelope was extracted.)
Profile extract functions (X'19' - X'1D', X'1F', X'20') Yes Yes. Each function code maps to a RACF listing command (For example, the authorization rules of the LISTGRP command). This authority can be skipped for a supervisor state caller if requested in the input parameter list. For problem state callers and for supervisor state callers who request it:
  • Extract user, extract next user, and extract connect - READ access to IRR.RADMIN.LISTUSER
  • Extract group and extract next group - READ access to IRR.RADMIN.LISTGRP
  • Extract resource and extract next resource - READ access to IRR.RADMIN.RLIST
Note:
  1. Generic FACILITY class profiles can be used.
  2. For the profile extract functions, it is possible that the caller is only authorized to see a subset of the profile information. In this case, only this subset of information is returned. If any information is returned, the caller receives a 0 return code, and no indication that information has been suppressed. Following are some situations in which information is suppressed (for problem state callers, and for supervisor state callers who have not requested that the command authority checks be bypassed). These situations are identical to the corresponding RACF command (e.g. LISTUSER, LISTGRP, and RLIST).
    • Only a user with the AUDITOR attribute (at either the group or system level) can view the UAUDIT setting of a USER profile, or the AUDITOR-related audit settings in a general resource profile.
    • Users can be authorized to view the BASE segment, but no additional segments.
    • With the use of field-level access checking (using the FIELD class), users can be authorized to view certain non-BASE segment information without having authority to view the BASE segment.
    • When certain SECLABEL-related SETROPTS options are in effect, the installation data field of the USER profile is suppressed for all but system SPECIAL users.
    • When a non-privileged user has at least READ, but not ALTER access to a general resource profile, the access list is not returned.
  3. For the SETROPTS extract function, it is possible that the caller is authorized to see only a subset of the SETROPTS information. In this case, only this subset of information is returned. If any information is returned, the caller receives a 0 return code, and no indication that information has been suppressed. For any caller who does not have the AUDITOR attribute, or the group-AUDITOR attribute in any of their groups, the auditing related fields are suppressed.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014