Controlling the use of operator commands

To control the use of operator commands, do the following:

Ask your system programmer for the following information:
1. The subsystem and resource name associated with the command to be authorized. The resource names are described in the following documents:
  - For MVS™ system commands, see z/OS MVS System Commands.
  - For JES2 commands, see z/OS JES2 Initialization and Tuning Guide.
  - For RACF® operator commands, you need to define profiles in the OPERCMDS class to control authorization.
    Important: If you do not define profiles for them, these commands cannot be protected. This means that anyone at a master console or a console with system authority would be able to use these commands. However, except for the DISPLAY command which does no additional authority checking, these commands check the console's attributes when no profile is found and can still fail the request. For the DISPLAY command, you should specify READ authority.
  For examples of resource names used when defining profiles in the OPERCMDS class, see Table 1 and Table 2. Other examples are as follows:
```
RDEFINE OPERCMDS RACF.SIGNOFF.** UACC(NONE)
PERMIT  RACF.SIGNOFF.** CLASS(OPERCMDS) ID(DJONES) ACCESS(UPDATE)

RDEFINE OPERCMDS RACF.DISPLAY.SIGNON.** UACC(NONE)
PERMIT  RACF.DISPLAY.SIGNON.** CLASS(OPERCMDS) ID(DJONES) ACCESS(READ)
```
  The base command or resource names are SIGNOFF and DISPLAY.SIGNON. Although SIGNON is not required at the console (because it is the default), it must be specified in the resource name to protect the DISPLAY command.
2. The UACC to be associated with the command.
3. The user IDs of the operators or the group names of the groups of operators to whom you want to grant authority.
4. For each operator or group of operators:
  - The access authority to be assigned to the operator or group of operators.
    - For RACF operator commands (shown in Table 1), the required access authority is READ, except for the SIGNOFF command which requires UPDATE authority.
    - For RACF TSO commands entered as operator commands (shown in Table 2). See Note 3.
  - Any restrictions on which consoles the operators must be using when issuing certain commands. To do this, create profiles for consoles in the CONSOLE class and then specify the WHEN(CONSOLE) operand on the PERMIT command. See Conditional access lists for general resource profiles.
    Note: To authorize a console to a command or group of commands, create a RACF user profile for the console and place the console's user ID (or a RACF group to which the user ID is connected) in the access list of the OPERCMDS profile.
Use the RDEFINE command to create profiles for the commands:
```
RDEFINE OPERCMDS profile-name UACC(NONE)
```
where profile-name is:
```
subsystem-name.command[.qualifier]
```
where:

subsystem-name

is the name of the processing environment of the command (such as MVS, JES2, or RACF)

command

is the name of the command

qualifier

is the type of object the command specifies (JOB or SYS, for example) or an operand of the command (LIST, for example)
In these examples, you would first issue SETROPTS GENERIC(OPERCMDS) to turn generics on for the OPERCMDS class and then issue SETROPTS REFRESH:
```
RDEFINE OPERCMDS JES2.CALL.**     UACC(NONE)
RDEFINE OPERCMDS RACF.TARGET.LIST UACC(NONE)
```
Note:
1. When an operator issues a command that the subsystem doesn't recognize, the subsystem checks for a profile named subsystem-name.UNKNOWN. To handle these commands, create a profile named:
  - MVS.UNKNOWN with UACC(READ) for MVS
  - JES2.UNKNOWN with UACC(NONE) for JES2
  - RACF.UNKNOWN with UACC(NONE) for RACF
  Your security policy might require auditing of all commands issued, even if they are not valid on your system. You can audit these commands by specifying AUDIT(ALL) on these profiles.

For each controlled command, grant access to the users or groups who need to use it:

PERMIT profile-name CLASS(OPERCMDS) ID(user or group ACCESS(access-authority)

For example:

PERMIT JES2.CALL.DSP.** CLASS(OPERCMDS) ID(OPER7 OPER24) ACCESS(UPDATE)

When you are ready to start controlling access to commands based on the profiles you have defined, activate the OPERCMDS class:
```
SETROPTS CLASSACT(OPERCMDS) RACLIST(OPERCMDS)
```

Example of Controlling Who Can Issue MVS Commands

The following example shows how to use the OPERCMDS class to control who can display and cancel jobs in your installation.

Suppose you want to let anyone display jobs but you want to restrict the task of cancelling jobs to a group of MVS operators. All of the MVS operators you want to authorize have RACF-defined user IDs connected to a group called OPERGRP.

According to z/OS MVS Planning: Operations, to authorize a user to issue the MVS DISPLAY JOBS command, you must give the user READ access to a resource named MVS.DISPLAY.JOB in the OPERCMDS class. To authorize a user to issue the MVS CANCEL command for all jobs, you must give the user UPDATE access to a resource named MVS.CANCEL.JOB.** in the OPERCMDS class.

To grant these authorizations, enter:

SETROPTS GENERIC(OPERCMDS) REFRESH

RDEFINE  OPERCMDS MVS.DISPLAY.JOB UACC(READ)
RDEFINE  OPERCMDS MVS.CANCEL.JOB.** UACC(NONE)

PERMIT   MVS.CANCEL.JOB.** CLASS(OPERCMDS) ID(OPERGRP) ACCESS(UPDATE)

SETROPTS CLASSACT(OPERCMDS)
SETROPTS RACLIST(OPERCMDS) REFRESH
SETROPTS GENERIC(OPERCMDS) REFRESH

Now, anyone can display a job, but only the operators in OPERGRP can cancel a job.

Table 1. RACF operator command profiles: Naming conventions
Command	Resource name
DISPLAY	`subsystem-name.`DISPLAY.SIGNON Any profile in the OPERCMDS class covering this resource name protects the DISPLAY command, for example: `RDEFINE OPERCMDS RACF.DISPLAY.SIGNON` Note: No OPERCMDS authority check is performed when the DISPLAY command is issued from a RACF parameter library member.
RESTART	`subsystem-name`.RESTART Any profile in the OPERCMDS class covering this resource name protects the RESTART command, for example: `RDEFINE OPERCMDS RACF.RESTART` Note: The RESTART command cannot be issued from a RACF parameter library member.
SET	`subsystem-name`.SET.AUTOAPPL `subsystem-name`.SET.AUTODIRECT `subsystem-name`.SET.AUTOPWD `subsystem-name`.SET.FULLRRSFCOMM `subsystem-name`.SET.GENERICANCHOR `subsystem-name`.SET.INCLUDE `subsystem-name`.SET.JESNODE `subsystem-name`.SET.LIST `subsystem-name`.SET.PWSYNC `subsystem-name`.SET.TRACE To protect the SET LIST command, for example: `RDEFINE OPERCMDS RACF.SET.LIST` Note: No OPERCMDS authority check is performed when the SET command is issued from a RACF parameter library member.
SIGNOFF	`subsystem-name`.SIGNOFF Any profile in the OPERCMDS class covering this resource name protects the SIGNOFF command, for example: `RDEFINE OPERCMDS RACF.SIGNOFF` Note: No OPERCMDS authority check is performed when the SIGNOFF command is issued from a RACF parameter library member.
STOP	`subsystem-name`.STOP Any profile in the OPERCMDS class covering this resource name protects the STOP command, for example: `RDEFINE OPERCMDS RACF.STOP` Note: The STOP command cannot be issued from a RACF parameter library member.
TARGET	`subsystem-name`.TARGET.DESCRIPTION `subsystem-name`.TARGET.DENYINBOUND Note: TARGET.DENYINBOUND also protects the ALLOWINBOUND and RESETDENYINBOUNDCOUNT operands. `subsystem-name`.TARGET.LIST Note: TARGET.LIST also protects the LISTALL and LISTPROTOCOL operands. `subsystem-name`.TARGET.MAIN `subsystem-name`.TARGET.NEWMAIN.`node-name`.`system-name` Note: TARGET.NEWMAIN.`node-name`.`system-name` also protects the PLEXNEWMAIN operand `subsystem-name`.TARGET.LOCAL `subsystem-name`.TARGET.NODE `subsystem-name`.TARGET.OPERATIVE Note: TARGET.OPERATIVE also protects the DELETE and DORMANT operands. `subsystem-name`.TARGET.PREFIX `subsystem-name`.TARGET.NEWPREFIX Note: TARGET.NEWPREFIX also protects the NEWWORKSPACE operand. `subsystem-name`.TARGET.PROTOCOL `subsystem-name`.TARGET.PURGE `subsystem-name`.TARGET.SYSNAME `subsystem-name`.TARGET.WDSQUAL `subsystem-name`.TARGET.WORKSPACE To protect the TARGET LIST command, for example: `RDEFINE OPERCMDS RACF.TARGET.LIST` Note: No OPERCMDS authority check is performed when the TARGET command is issued from a RACF parameter library member.

Table 2. RACF TSO commands entered as operator commands: Naming conventions
Command	Resource name
ADDGROUP or AG	`subsystem-name`.ADDGROUP
ADDSD or AD	`subsystem-name`.ADDSD
ADDUSER or AU	`subsystem-name`.ADDUSER
ALTDSD or ALD	`subsystem-name`.ALTDSD
ALTGROUP or AG	`subsystem-name`.ALTGROUP
ALTUSER or ALU	`subsystem-name`.ALTUSER
CONNECT or CO	`subsystem-name`.CONNECT
DELDSD or DD	`subsystem-name`.DELDSD
DELGROUP or DG	`subsystem-name`.DELGROUP
DELUSER or DU	`subsystem-name`.DELUSER
LISTDSD or LD	`subsystem-name`.LISTDSD
LISTGRP or LG	`subsystem-name`.LISTGRP
LISTUSER or LU	`subsystem-name`.LISTUSER
PASSWORD or PW or PHRASE	`subsystem-name`.PASSWORD
PERMIT or PE	`subsystem-name`.PERMIT
RACLINK	`subsystem-name`.RACLINK
RALTER or RALT	`subsystem-name`.RALTER
RDEFINE or RDEF	`subsystem-name`.RDEFINE
RDELETE or RDEL	`subsystem-name`.RDELETE
REMOVE or RE	`subsystem-name`.REMOVE
RLIST or RL	`subsystem-name`.RLIST
SEARCH or SR	`subsystem-name`.SEARCH
SETROPTS or SETR	`subsystem-name`.SETROPTS
Note: RACF first checks that the operator issuing the TSO command is defined to RACF and if not, an error message is issued. If the operator is defined to RACF, a check is made to a profile in the OPERCMDS class to determine if the user ID has authority to issue the TSO command as an operator command. If the OPERCMDS class is not active, or if no OPERCMDS profile exists, the user will be allowed to issue the command as an operator command. Existing command authorization is still enforced. For example, you must be a SPECIAL user to issue the SETROPTS INITSTATS command. READ access is required to all the resource names shown in Table 2 with the exception of SETROPTS. If SETROPTS LIST is issued with no other operands, READ access is sufficient. However, if any other SETROPTS option is issued, with or without also specifying LIST, UPDATE access is required. If your installation renames any RACF TSO commands, they are still protected under the resource names shown in Table 2. For example, if you renamed ADDGROUP as ADDBUNCH, RACF would still use `subsystem-name`.ADDGROUP as the resource name.