Using NEXTKEY

The NEXTKEY operand splits a very large rule set into several sets. Specify the rule ID of an alternate rule set in the NEXTKEY operand. If the environment and permissions of the current rule set prevents access to a command, CA ACF2 for z/ VM searches the alternate rule set specified through NEXTKEY.

When NEXTKEY specifies an alternate rule set, a security administrator must grant authority to whoever is responsible for writing and maintaining that command limiting rule set through the %CHANGE control statement. This control statement must reside in the alternate rule set that the security administrator must initially establish.

For a %CHANGE authorization to be active, you must specify the CHANGE operand of the RULEOPTS VMO record. If you specify NOCHANGE, all %CHANGE authorizations are inactive. The default is CHANGE. This default is required to use %CHANGE.

Splitting Rule Sets

As stated before, the NEXTKEY operand splits a command limiting rule set. This may be necessary to selectively delegate rule maintenance (%CHANGE) authority. Or you may need to use it if a rule set is very large and exceeds the 4K physical storage size limit.

For example, you can have several entries for a rule set, all under the same CP command, ATTACH. The NEXTKEY feature can redirect or split the rule set for ATTACH into smaller sets as follows:

$KEY(ATTACH)
 580 TO USERID AS *- NEXTKEY(A)
 581 TO USERID AS *- NEXTKEY(B)
 582 TO USERID AS *- NEXTKEY(C)

In the above example, USERID is a pseudo-operand that matches any user ID. The first three rule entries specify the NEXTKEY rule sets to validate access to real devices 580, 581, and 582. You can then write three smaller rule sets as follows:

$KEY(A)
$MODEL(ATTACH)
%CHANGE SECDIR
 - UID(*) ALLOW

$KEY(B)
$MODEL(ATTACH)
%CHANGE OPSDIR
 - UID(OPR) ALLOW

$KEY(C)
$MODEL(ATTACH)
%CHANGE PRGDIR
 - UID(PRG) ALLOW

These rule sets let you delegate authority through the %CHANGE control statement, but they are smaller than a single rule set required for the ATTACH command. Specify the $MODEL control statement to indicate that CA ACF2 for z/ VM is to use this syntax model during compilation to syntax check the rule entries.

Examining the last three examples, the first rule set for device 580 specifies a %CHANGE control statement to allow the Director of Security (SECDIR) to change rule entries governing only device 580. The second rule set grants similar authority to the Director of Operations (OPSDIR) for device 581. The third rule set grants similar authority to the Director of Programming (PRGDIR) for device 582.

Computer operators (OPR) can only attach device 581. The second example rule set ($KEY(B)) allows this access. Similarly, programmers (PRG) can attach device 582 because of the third rule set.

The NEXTKEY operand directs CA ACF2 for z/ VM validation only when access based on the current rule set is prevented. You can have a chain of up to 25 NEXTKEY operands. If you specify more than 25, CA ACF2 for z/ VM denies access and writes a KEYEXCES violation record that appears on the ACFRPTCL report. You cannot reference the same rule set twice during a single validation. That is, the chain of NEXTKEY options cannot form a loop. If you reference the same rule set twice, CA ACF2 for z/ VM denies the access and writes a NKEYLOOP violation record to the ACFRPTCL report. For more information about ACFRPTCL and NEXTKEY reporting, see the Reports and Utilities Guide.