Associating started procedures and jobs with user IDs

A procedure (PROC) consists of a set of job control language statements that are frequently used together to achieve a certain result. PROCs usually reside in the system procedure library, SYS1.PROCLIB, which is a partitioned data set. A started procedure is normally started by an operator, but can be associated with a functional subsystem. For example, DFSMS is treated as a started task even though it does not need to be specifically started with a START command.

Only RACF-defined users and groups can be specifically authorized to access RACF-protected resources. However, started procedures have system-generated JOB statements that do not contain the USER, GROUP, or PASSWORD parameter.

To enable started procedures to access the same RACF-protected resources that users and groups access, started procedures must have RACF® user and group identities. By assigning them RACF identities, your installation can give started procedures specific authorization to access RACF-protected resources. For example, you can allow JES to access spool data sets.

As with any other user ID and group name, the user ID and group name that you assign to a started procedure must be defined to RACF using the ADDUSER and ADDGROUP commands.

Guideline: Define the user ID assigned to a started procedure to be a protected user ID, so that the user ID cannot be revoked by incorrect password or password phrase attempts or used to enter the system in ways that require a password or password phrase.

To define a user ID as protected, assign it the NOPASSWORD, NOPHRASE, and NOOIDCARD attributes using the ADDUSER or ALTUSER command. You might also need to use the PERMIT command to authorize the users or groups to get access to the required resources. For descriptions of the commands, see z/OS Security Server RACF Command Language Reference. For information on protected user IDs, see z/OS Security Server RACF Security Administrator's Guide.

The started procedure name is always available to the exit routines, whether or not the name is coded in the module. It is available in the parameter list for RACROUTE REQUEST=VERIFY exits and in the ACEE for RACROUTE REQUEST=AUTH and RACROUTE REQUEST=DEFINE exits.

If a started procedure is executed without associating its name with a RACF-defined user ID and group name, the started procedure runs as an undefined user. The procedure can access RACF-protected resources if the universal access authority for the resource is sufficient to allow the requested operation. However, if a started procedure uses a RACF-protected resource that grants or denies authority based on access list entries, you must associate the started procedure with a RACF-defined user ID and group name.

No user verification (password checking) takes place for a started procedure's user ID. However, you should still specify a password on the ADDUSER command for a started procedure. If you do not specify a password, RACF uses the user ID default group as the password. Any user who knows the started procedure's default group can use the user ID and default password to access the system.

RACF allows a started task or job to run even if the user ID is revoked.

RACF allows you to specify that a started procedure is privileged; this means that most authorization requests done for the procedure are considered successful, without actually performing any checking. This includes bypassing the checks for security classification on users and data. Additionally, the following processing is affected.

For RACROUTE REQUEST=AUTH, RACF:
- Does not call any exit routines
- Does not generate any SMF records
- Does not update any statistics
For RACROUTE REQUEST=FASTAUTH, RACF
- Calls exit routines as usual
- Does not generate any SMF records
- Does not update any statistics
For RACROUTE REQUEST=DEFINE,
- The checking done for the CHKAUTH operand is bypassed
- All other RACF processing occurs as usual

RACF allows you to specify that a started procedure is trusted; this means that most authorization requests done for the procedure are considered successful, without actually performing any checking. This includes bypassing the checks for security classification on users and data. Additionally, the following processing is affected.

For RACROUTE REQUEST=AUTH, RACF:
- Does not call any exit routines
- Generates SMF records based on the audit options specified in SETROPTS LOGOPTIONS and the UAUDIT setting in the user ID profile
- Does not update any statistics
For RACROUTE REQUEST=FASTAUTH, RACF
- Calls exit routines as usual
- Generates SMF records based on the UAUDIT setting in the user ID profile
- Does not update any statistics
For RACROUTE REQUEST=DEFINE,
- The checking done for the CHKAUTH operand is bypassed
- All other RACF processing occurs as usual

The trusted bit is used in a B1 system to indicate that the entry is part of the trusted computing base.

Guideline: Assign the TRUSTED attribute when one of the following conditions applies:

The started procedure or address space creates or accesses a wide variety of unpredictably named data sets within your installation.
Insufficient authority to an accessed resource might risk an unsuccessful IPL or other system problem.

For a list of required and optional candidates for the TRUSTED attribute, see "Assigning the RACF TRUSTED attribute " in z/OS MVS Initialization and Tuning Reference.

A trusted or privileged started task is treated as a z/OS UNIX System Services superuser if any z/OS UNIX user identifier (UID) is assigned to it in the OMVS segment. It does not have to have a UID of 0 to be considered a superuser.

Note:

If ENTITY=(...,CSA) or ENTITY=(...,PRIVATE) is coded on the RACROUTE REQUEST=AUTH macro instruction, RACF ignores the privileged and trusted attributes and performs normal authorization processing.
If the requested class is defined, active, and appropriately RACLISTed (if required), then except as mentioned in Note 1, a started procedure that has the privileged or trusted attribute accepts any checking done by RACROUTE REQUEST=AUTH and RACROUTE REQUEST=FASTAUTH, including security classification checking, and returns a return code of 0 (access allowed). A started procedure can also access resources during failsoft processing without having RACF prompt the operator for permission. (For a discussion of failsoft processing, see Failsoft processing.)
While the trusted and privileged attributes are usually associated with started tasks, a RACROUTE REQUEST=VERIFY exit can mark other ACEEs privileged or trusted. RACF then processes those users in the same way as it does trusted or privileged started tasks.