To control the use of operator commands, do the following:
- 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:
- 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.
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 conventionsCommand |
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 |
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 conventionsCommand |
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.
|