Controlling the use of operator commands

To control the use of operator commands, do the following:
  1. 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 JES3 commands, see z/OS JES3 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.

      The RVARY command cannot be protected by profiles in the OPERCMDS class. This is intentional during recovery; RACF must not be allowed to attempt to access the database. The RVARY command is always protected by an operator prompt, regardless of whether it is entered from TSO or as an operator 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.
  2. 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, JES3, 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 JES3.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 or JES3.UNKNOWN with UACC(NONE) for JES
      • 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.

  3. 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 JES3.CALL.DSP.** CLASS(OPERCMDS) ID(OPER7 OPER24) ACCESS(UPDATE)
  4. 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.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
  • Start of changesubsystem-name.TARGET.NEWPREFIX
    Note: TARGET.NEWPREFIX also protects the NEWWORKSPACE operand.
    End of change
  • 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:
  1. 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.
  2. Existing command authorization is still enforced. For example, you must be a SPECIAL user to issue the SETROPTS INITSTATS command.
  3. 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.
  4. 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.