Previous Topic: STORE SubcommandNext Topic: Using the ACF Command (DIAGLIM Setting)


TEST Subcommand

The TEST subcommand puts you in an environment where you can interactively test a compiled command limiting rule set. Testing can give you an idea of whether the rule set provides the protection you want.

Syntax of the TEST Subcommand

The syntax of the TEST subcommand is shown below.


TEST   { *     }    [MLTYPE(mltype)]
       { ruleid}

The TEST subcommand takes the following parameters:

*

Tests a previously compiled (but not necessarily stored) or decompiled command limiting rule set.

(no parameter)

When specified without a parameter, the TEST subcommand operates the same as when you specify an asterisk.

ruleid

Identifies the key of a command limiting rule set to be tested.

MDLTYPE(mdltype)

Specifies the operating system and release of the rule to be tested. If you do not specify a MDLTYPE, CA ACF2 for z/ VM uses your default model type (as defined in the CMDLIM VMO record).

TEST Subcommand Keywords

After you have issued the TEST subcommand along with any of the parameters described, the TEST subcommand is active. You can enter any of the keywords and values described below to specify a test access environment. You must separate each keyword with a blank character. You can enter all keywords on a single line or use separate lines to enter each keyword.

OPERANDS(operands)

Specify the OPERANDS keyword with the CP command operands to be tested. These operand names must be separated by blank characters. You cannot mask the command operands. You do not need to specify the CP command name since it is taken from the rule ID. You can also use the abbreviation O for OPERANDS.

UID(uidmask)

Specify the UID keyword with the UID string identifying the user to be tested. You can mask this UID string. To specify this keyword, you do not need access to the corresponding logonid record. If you specify both LID and UID, CA ACF2 for z/ VM uses the last LID or UID value specified. For example, if you specify LID(TLCJJD) UID(TLCNLT), CA ACF2 for z/ VM uses only UID(TLCNLT). If you do not specify a CLASS, the testing function uses your current class.

LID(lid)

Specify the LID keyword with the logon ID identifying the user to be tested. You cannot mask this logon ID . To specify this keyword, you do not need access to the corresponding logon ID record. It will be obtained from the service machine for testing purposes. If you specify both LID and UID, CA ACF2 for z/ VM uses the last LID or UID value specified. For example, if you specify UID(***TLCNLT) LID(TLCJJD), CA ACF2 for z/ VM uses only LID(TLCJJD). If you do not specify a CLASS, the testing function obtains the CP privilege class for the indicated logon ID from the VM directory.

CLASS(classes)

Specify the CLASS keyword with the CP privilege classes that you want to test the command operands against. Valid classes are A through Z and 1 through 6. Only those classes that apply to the particular release of VM you are running match the classes on the command models. Using the CLASS keyword can be particularly useful if you are testing rules for groups of users. If you do not specify either an unmasked logon ID or classes, your current CP privilege class is used for testing purposes. If you do not specify a CLASS, the testing function obtains the CP privilege class for the indicated UID from the VM directory.

DATE(date)

Specify the DATE keyword with the date to be tested. This date must be in the format selected during installation of CA ACF2 for z/ VM (mm/dd/yy, dd/mm/yy, or yy/mm/dd). The current date is assumed as a default.

SOURCE(sourceid)

Specify the SOURCE keyword with the logical name of the input source or source group.

TIME(hhmm)

Specify the TIME keyword with the time, in hours (hh) and minutes (mm). CA ACF2 for z/ VM uses this time to test the access.

How to Use the TEST Subcommand

Suppose you just compiled or decompiled a command limiting rule set with the key SPOOL:

acf
ACF
set cmdlim
CMDLIM
decomp spool
ACFpgm556I 'rule' rule 'key' stored by 'lid' on 'date'
$KEY(SPOOL) MDLTYPE(530)
$USERDATA (PROTECT THE SPOOL COMMAND)
 CON PURGE UID(****OPR) LOG
 PRINT COPY ‑ ALLOW
 PRINT RSCS ALLOW
 ‑ UID(*) ALLOW
ACFpgm551I Total record length='length' byte ‑ 'percent' percent
      utilized
CMDLIM

The TEST subcommand could then be issued:

te
 ACFpgm742I CMD='cmd', MDLTYPE='model'
 ACFpgm734I USERDATA contents: 'text'

At this point, the TEST subcommand is active. Because we did not specify a MDLTYPE in the DECOMP SPOOL subcommand line, CA ACF2 for z/ VM uses E21 (the site default) for the MDLTYPE. You can now enter any of the TEST subcommand keywords to specify the particular environment that you want to test.

For example, the following keywords test whether the command limiting rule set named SPOOL lets TLCNOPRNAS execute the SPOOL command with the operands CON and PURGE.

operands(con purge) UID(tlcnoprnas)
ACFpgm740I The following parameters are in effect:
 UID=TLCNOPRNAS SOURCE=********
 DATE=11/28/00 TIME=********
 CLASS=********
 OPERANDS=CON PURGE
 
THE FOLLOWING WOULD APPLY: LOG
   (RELATIVE RULE ENTRY 00001)
 .(signals you can enter more TEST subcommand keywords)
end (signals the end of TEST subcommand)
CMDLIM

We recommend you decompile before a test so you can see how CA ACF2 for z/ VM sorted your rule entries. If you do not decompile first, the TEST command results can be deceiving (TEST may report a relative rule entry 0003 applied when you know that the first rule entry you wrote should apply).

While the TEST subcommand is active, only command limiting rule interpretation is done. This testing does not take into account any virtual machine configurations, such as virtual unit record devices. Your unit record configuration is used. This should not cause any problems if you used the pseudo operand rule writing technique described earlier (if your virtual console was at 009 and the user's console was at 00A.) You could specify CON or 009 to test the SPOOL command and have the CON rule apply. When the user whose virtual console was at 00A issued a SPOOL 00A..., the CON rule applies.

How to Interpret TEST Results

As you can see in the previous example, CA ACF2 for z/ VM responds to the TEST request by displaying all of the current values that describe the environment being tested. At the bottom of the display is an indication of whether the command with the specified operand combination is allowed, logged, denied, or if there are any overrides, such as SYNERR or security. In the previous example, the result is that user TLCNOPRNAS is allowed to execute the CP command with the specified operand combination. The first rule entry in the rule set (as sorted by CA ACF2 for z/ VM) allowed the execution. Nearly all keyword values that are not specified are assumed to be completely masked, by default. (The values for the DATE, CLASS, and OPERANDS keywords are the only exceptions.) For instance, if you do not specify the UID keyword, the subcommand tests whether all UIDs are allowed access. For an explanation on how CA ACF2 for z/ VM obtains the CP privilege CLASS, see the LID and CLASS keywords in the TEST Subcommand Keywords section.

The results of the TEST subcommand show whether execution of the specified format of the CP command is allowed, logged, or prevented.

ALLOW

Access is allowed

LOG

Access is allowed but logged

PREVENT

Access is specifically prevented.

If no rule entry specifically applies to the test access environment, CA ACF2 for z/ VM displays the following message:

No rules apply, access would be denied

After a result is displayed, you can enter other keywords and values to specify another environment for testing. The END subcommand stops the TEST subcommand.