Controlling the use of operator commands
- Ask your system programmer for the following information:
- 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.
- The UACC to be associated with the command.
- The user IDs of the operators or the group names of the groups of operators to whom you want to grant authority.
- For each operator or group of operators:
- The access authority to be assigned to the operator or group of operators.
- 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.
- The subsystem and resource name associated with the command to
be authorized. The resource names are described in the following documents:
- 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:- 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.
- 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)
- 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.
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.
Command | Resource name |
---|---|
DISPLAY | subsystem-name.DISPLAY.SIGNON Any
profile in the OPERCMDS class covering this resource name protects
the DISPLAY command, for example:
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:
Note: The
RESTART command cannot be issued from a RACF parameter
library member.
|
SET |
To protect the SET LIST command, for example:
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:
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:
Note: The
STOP command cannot be issued from a RACF parameter
library member.
|
TARGET |
To protect the TARGET LIST command, for example:
Note: No
OPERCMDS authority check is performed when the TARGET command is issued
from a RACF parameter library
member.
|
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:
|