You have already learned how you can write access rules that define who can access information and resources and how that access is controlled.
Command limiting rules also control access, but provide further flexibility in validating users and the information they can use on the system. Through command limiting rules, you can control which Control Program (CP)commands and operands a user can execute.
A command limiting rule set contains the rules for a particular CP command. For example, one rule set can control the SPOOL command while another rule set controls the SET command. Each command limiting rule set consists of control statements and rule entries.
The control statements in a command limiting rule set include:
Specifies the full name of the CP command that the rule set applies to.
Associates the rule with a particular release of VM. It can also provide separate rule sets when systems share the same databases.
Specifies the mode for command limiting validation. It provides another way of changing the system‑wide mode for command limiting validation.
Prevents CA ACF2 for z/VM from sorting the rule set.
Specifies the owner of the rule set for tracking purposes.
Stores rule set information.
Each rule entry specifies an environment where a CP command can occur. These parameters can indicate:
Specifies the operands of the CP command being issued
Specifies those users that can issue the CP command with the specified operands
Specifies any time limitation (you can specify the number of days or a date) when a user can issue the command and operands.
Each rule entry also specifies an access permission, which determines how CA ACF2 for z/VM handles an attempt to issue a CP command under a particular environment. These permissions are:
Allows execution of the CP command under the specified conditions
LOG
Allows execution but writes a record to log the attempt
PREVENT
Denies execution and logs the attempt.
Masking in command limiting rules reduces the number of rule entries that you need to write. The number of rule entries is reduced because you can write a rule to allow:
For example, the following rule set applies to users in the Payroll Department at the True Lock Company. This rule set lets those users issue the SPOOL command with the PRINT operand and one other operand of one to four characters. (Command limiting rules usually contain more than one rule entry.)
$KEY(SPOOL) PRINT **** UID(TLCPAY‑) ALLOW
In this example, each asterisk can match any character including trailing blanks. The dash (—) represents any characters that completes the character string. In this case, UID(TLCPAY—) is the same as UID(TLCPAY*************) or UID(TLCPAY), because any specified UIDs are treated as if they were masked with a trailing dash.
The following example illustrates a command limiting rule set for the CP SET command:
$KEY(SET) MDLTYPE(H50) FAVORED — UID(AUTOLOG1) ALLOW FAVORED — UID(OPERATOR) LOG FAVORED — UID(*) PREVENT PRIORITY — UID(AUTOLOG1) ALLOW PRIORITY — UID(OPERATOR) LOG PRIORITY — UID(*) PREVENT SRM — UID(MAINT) LOG SRM — UID(*) PREVENT — UID(*) ALLOW
This example allows user AUTOLOG1 to issue the SET FAVORED and SET PRIORITY commands. The OPERATOR user ID can issue the SET FAVORED and SET PRIORITY commands, but they will be logged. MAINT can issue the SET SMR command, but it will be logged. By default, all other users are prevented from issuing the SET FAVORED, SET PRIORITY and SET SRM commands. The last rule entry allows users to issue all other operand combinations of the SET command without logging or preventing them.
You can determine the CP commands that CA ACF2 for z/VM validates. When a CP command is validated, command limiting rules determine who can issue the command, under what conditions the command can be issued, and with what operands the command can be issued.
|
Copyright © 2009 CA Technologies.
All rights reserved.
|
|