You can control whether users can receive messages sent with the
TSO SEND command.
Note: - When the SMESSAGE class is active and a profile does not exist
for the specified user, the SEND command completes normally.
- When the SECLABEL class is active, the receiver of the message must
pass the security label authorization check based on the receiver's
current security label and the security label of the message (which
was set by the sender's current security label at the time that the
sender issued the TSO SEND command.)
To control the use of the TSO SEND command, do the following:
- Create profiles in the SMESSAGE class:
RDEFINE SMESSAGE userid-of-receiver UACC(NONE)
- Give users the appropriate access authority:
PERMIT RECVR1 CLASS(SMESSAGE) ID(SENDER1) ACCESS(READ)
PERMIT RECVR2 CLASS(SMESSAGE) ID(SENDER2) ACCESS(NONE)
where
SENDER1 and SENDER2 are valid RACF® user
IDs or group names, and RECVR1 and RECVR2 are valid RACF user IDs. The first PERMIT in the
example allows SENDER1 to send messages to RECVR1. The second PERMIT
in the example prevents SENDER2 from sending messages to RECVR2.
- When you are ready to start using the security provided
by these profiles, activate both the DIRAUTH class and the SMESSAGE
class, and activate SETROPTS RACLIST processing for the SMESSAGE class.
SETROPTS RACLIST processing helps ensure high performance when access
authorities are checked. You can do these actions in one command:
SETROPTS CLASSACT(SMESSAGE DIRAUTH) RACLIST(SMESSAGE)
Note: Any
time you make a change to an SMESSAGE profile, you must also refresh
SETROPTS RACLIST processing for the SMESSAGE class for the change
to take effect. For example:
SETROPTS RACLIST(SMESSAGE) REFRESH
z/OS Security Server RACF Security Administrator's Guide
Copyright IBM Corporation 1990, 2014