Writing Rules › How Do You Specify CA ACF2 Option for DB2 Rules? › Control Statements › Placement of Control Statements › Types of Control Statements:

Types of Control Statements:

The types of control statements are explained below.

$KEY(resourcename)

Identifies the DB2 resource or resources this rule applies to. You specify the $KEY differently depending on the resource. The $KEY control statement is required.

A resource name is from one to 252 characters long, depending on whether it is unqualified or qualified.

• An unqualified resource name is a one to 252‑character string with no periods delimiting sections or qualifiers of the resource name.
• A qualified resource name is in the format qualifier1.qualifier2…, where the first qualifier is one to 250 characters long, followed by a period and one or more subsequent qualifiers. All the qualifiers together make up the complete resource name. The maximum length for qualified resource names is 252 characters.

  Extended resource keys can also be used to protect resources with qualified resource names.

  The resource name ($KEY) can contain embedded blanks. However, when you decompile the rule set with a $KEY that contains embedded blanks, you must enclose the resource name in single quotes as follows:

  DECOMP 'KATHY.ABC 123'

  You can also mask this field to create rules that control similarly named resources. You must make the directory resident in common storage for the specified type of resource (see “What Are Rule Directories” for information about directories.) To mask the $KEY, use only asterisks (*). The number of characters, including asterisks, must correspond to the maximum number of characters in the resource names that you want to match.

Follow these guidelines in specifying the $KEY value for a resource rule:

• When the resource name is a single unqualified resource name, you must specify the entire resource name or its masked equivalent in the $KEY. For example:

  Resource name:  TESTNAME
  

  Sample $KEY values:  TESTNAME
  

                           ****NAME
                           TEST****
  

  Sample resource rule: 
  

  $KEY(TESTNAME) TYPE(PLN) SYSID(DSNP)
  

   UID(‑) SERVICE(EXECUTE) ALLOW
  

• When the resource name is a qualified resource name, you can specify the entire resource name (or its mask) as the $KEY value, or the high‑level qualifier (or its mask) in the $KEY value for the rule, with the remainder of the resource name specified in the extended resource rule key field of the individual rule lines. For example:

  Resource name:  TEST.TABLE
  

  Sample $KEY values:  TEST.TABLE
  

                           TEST.*****
                           **********
                           TEST
                           T**T
                           ****
  

  Sample resource rules:
  

  $KEY(TEST.*****) TYPE(TBL) SYSID(DSNP)
  

   UID(‑) ALLOW
  

  $KEY(TEST) TYPE(TBL) SYSID(DSNP)
  

   TABLE       UID(‑) SERVICE(SELECT) ALLOW
   OTHER       UID(‑) SERVICE(SELECT) ALLOW
   ‑           UID(‑) SERVICE(SELECT) LOG
  

• When a qualified resource name is specified in the $KEY value, extended resource keys cannot be specified in any of the resource rule lines.

  For example:

  $KEY(TEST.TABLE) TYPE(TBL) SYSID(DSNP)
  

  NAME UID(‑) ALLOW
  

  Will generate the following compiler error:

  ACFD2041 SECOND LEVEL QUALIFIER NOT ALLOWED WITIN THIS RULESET
  

  You can use resource grouping with the $KEY to create a single rule set for multiple resources.

  Note: In the case of synonyms used for table names in DB2, the resource name ($KEY) must be the true table name, not the synonym.

  The type of resource determines the maximum number of characters permitted for this field, as follows:

Note: When the resource name is longer than forty characters, you must specify the high-level qualifier or its masked equivalent in the $KEY value for the rule. Specify the remainder of the resource name (or its mask) in the extended resource rule key field of the individual rule entry lines.

• For system privileges and utilities, the $KEY identifies the specific privilege. Unlike other DB2 resources, system privileges and utilities are not associated with a physical entity such as a database, table, application plan, or other DB2 object. Some system privileges are administrative authorities that can represent multiple DB2 privileges.

  For system privileges and utilities, the $KEY can be one of the following. You cannot mask or abbreviate these values.

1To control the BINDAGENT system privilege, format the $KEY control statement as follows:

$KEY(BINDAGENT.logonid)

The value logonid is any valid logonid. It represents the logonid that is granting BINDAGENT to another user. You can mask this value.

If extended resource keys are used, the $KEY control statement can be specified as follows:

$KEY(BINDAGENT)

$LIDOWNER(logonid)|$UIDOWNER(uidmask)|$ROLOWNER(role)

Applies only to rules written for application plans, databases, distinct types, functions, JAVA archive files, roles, sequences, storage groups, stored procedures, tables (and views), table spaces, and trusted contexts. $UIDOWNER is only valid for UID rules, not for $ROLESET. $ROLOWNER is only valid for $ROLESET rules.

These parameters identify one or more owners of these resources. Owners of resources are granted all access privileges, but are not granted the right to administer security. Unlike native DB2 security, CA ACF2 Option for DB2‑defined owners cannot create, change, or delete CA ACF2 Option for DB2 rule sets (that is, privileges in DB2) unless a security administrator gives them this ability through the %CHANGE or %RCHANGE control statement. See Comparing DB2 and CA ACF2 Option for DB2 Features for more information about ownership in CA ACF2 Option for DB2 and DB2.

System privileges, buffer pools, collections, and schemas are not owned, so $LIDOWNER and $UIDOWNER do not apply to these resources.

When you specify $LIDOWNER, this eight‑character logonid owns the resource. You cannot mask this field. When you specify $UIDOWNER, any user whose user identification string (UID) matches the mask owns the resource. For example, if you specify CH******* as $UIDOWNER, where CH represents Chicago, any Chicago user is considered the owner and has arolll the privileges that ownership in CA ACF2 Option for DB2 grants. When you specify $ROLOWNER, all users who belong to this eight-character role own the resource. You cannot mask the $ROLOWNER.

$MEMBER(membername)

Specifies the member name to be used for a decompile into a partitioned data set (PDS) if one is not provided with the decompile request. For an explanation of how the $MEMBER control statement affects processing of the DECOMP subcommand, see the CA ACF2 Administrator Guide.

When you specify a $MEMBER name that matches the $KEY value for the resource rule, a warning is issued and the $MEMBER control statement is ignored.

$MODE(ABORT|LOG|QUIET)

Specifies what CA ACF2 Option for DB2 does when a user attempts to use the resource this rule set protects and is denied. This parameter is effective only when you specify RULE mode for this particular resource type in the DB2 OPTS infostorage record. When you specify RULE mode, CA ACF2 Option for DB2 rule validation is based on the value contained in this control statement.

For example, based on the following rule, only the users whose UIDs begin with NYFAC are permitted access to the ACCTPAY.MONTHLY_DATA table.

$KEY(ACCTPAY.MONTHLY_DATA)
$TYPE(TBL)
$MODE(LOG)
$SYSID(****)
 UID(NYFAC) SERVICE(SELECT,INSERT) ALLOW

These users have only SELECT and INSERT privileges for this resource. If they attempt to perform a function with this resource other than SELECT or INSERT, this rule entry does not apply. If no rule applies, CA ACF2 Option for DB2 checks the DB2 OPTS record for that particular resource. In this example, if you specify RULE mode for the TBLMODE field in the DB2 OPTS record, access is permitted to the resource based on the $MODE(LOG) control statement in this rule.

The $MODE control statement eases the transition to full security by phasing in protection at the rule set level. You can also use this control statement to eliminate the need for a postvalidation or violation exit for this type of checking during the transition period. The $MODE control statement values are:

$NORULELNG

Overrides the use of the rulelong compiler when RULELONG is active. Normally, CA ACF2 uses the rulelong compiler to compile rules if the RULELONG option is set. This rulelong format is an expanded record format. If a ruleset is small and therefore does not require the rulelong format, specifying NORULELNG in the rule set lets you compile the rule using a more compact record format.

$NOSORT

Prevents CA ACF2 Option for DB2 from sorting the rules in this rule set when it is stored. The rules remain in the order they were first entered into the compiler through the terminal or partitioned data set (PDS). Without $NOSORT, CA ACF2 Option for DB2 sorts and stores the rules from most specific to least specific in terms of access environment. See CA ACF2 Resource Rule Validation for more information about sorting.

You should use $NOSORT with caution, because CA ACF2 Option for DB2 always uses the first rule that matches the access environment. $NOSORT can cause a more general rule to be evaluated before a more specific rule. For this reason, CA ACF2 Option for DB2 issues a warning message when you compile a rule set containing a $NOSORT statement. To use $NOSORT, you must set the NOSORT field in the GSO RULEOPTS record. See the chapter that explains GSO records in the CA ACF2 Administrator Guide for more information about $NOSORT.

$OWNER(ownerid)

Specifies the owner of the rule. You can specify up to 24 characters in the $OWNER control statement. CA ACF2 Option for DB2 provides the $OWNER statement in case you want to track ownership of a rule. CA ACF2 Option for DB2 does not use this field for any processing. The $OWNER statement does not grant the specified user any special privileges regarding the rule set.

CA ACF2 Option for DB2 stores the $OWNER data with the rule set and displays it when you decompile the rule set (similar to the $USERDATA information). CA ACF2 Option for DB2 also stores the $OWNER data in SMF records that can be used to produce reports. You can use your own conventions for the information placed in $OWNER to facilitate reporting methods.

$PREFIX(prefix)

Provides additional or alternate matching criteria for the resource name being validated. The $PREFIX statement is most useful when specified with the NEXTKEY parameter, but it can be specified in any resource rule.

Use the $PREFIX control statement to specify a one to 252‑character alternate key value with the format qualifier1.qualifier2....

After CA ACF2 Security Option for DB2 selects a resource rule for validation based on the $KEY value, it processes the $PREFIX statement if one exists. Regardless of how the rule was selected for validation, the full resource name is matched against the $PREFIX value. After it performs this match, CA ACF2 Security Option for DB2 uses any unmatched portion of the resource name to match against the extended resource keys specified in the resource rule lines. For example, with a resource name of TEST.TESTNAME2, you could create the following resource rule:

$KEY(TEST) TYPE(TBL) SYSID(TEST)           qualifier match
$PREFIX(TEST.*********)                    matches full resource name
UID(...) ...SERVICE(SELECT)                no extended resource key

When the $PREFIX value does not match the equivalent part of the resource name, access is denied to the resource. For example, with the resource name of TEST.TESTNAME2, you could create the following resource rule:

$KEY(TEST.TESTNAME*) TYPE(TBL) SYSID(TEST)  full key match
$PREFIX(TEST.SOMETHING)                     doesn't match resource name
UID(...) ...

Access is denied.

When you specify $PREFIX(), a warning message is issued to indicate that the $PREFIX is null and is ignored.

$ROLESET

Designates this rule set as a role rule set that must contain role parameters in rule line entries. UID parameters are NOT allowed in this rule set. ROLE and USER are valid parameters on roleset rule line entries.

$SYSID(sysidmask)

Identifies the DB2 subsystem, subsystem mask, or group SYSID this rule set pertains to. The one‑ to four‑character subsystem ID associated with a particular DB2 subsystem is defined in the IEFSSNxx member of SYS1.PARMLIB. With this field, you can define different rules for each subsystem.

If you want more than one DB2 subsystem to use this rule, you can mask this field. To mask the $SYSID, use only asterisks (*) for masking characters. The number of characters, including asterisks, must correspond to the exact number of positions in $SYSID (that is, four). For example, a rule written with a $SYSID of DB** applies to all DB2 subsystems that begin with DB.

You can also share resource rules among DB2 subsystems by using a group SYSID in this field. You assign a group SYSID to a DB2 subsystem by specifying a GSYSID value in the DB2 OPTS record for the subsystem. You should then use the group SYSID as the $SYSID value in the resource rules. This enables multiple DB2 subsystems to share resource rules even when their SYSID's cannot be masked to a common value.

$TYPE(typecode)

Specifies the type of DB2 resource that this rule set applies to. The type code groups CA ACF2 Option for DB2 rules so that they can be identified for a particular type of resource. The $TYPE control statement is required. This type code can be:

$USERDATA(text)

Contains up to 64 characters of data for your use. This information is stored with the rule set. Any site postvalidation or violation exit can access this information to indicate further checking or control information. You can also use the DATA parameter (described under the Rule Entries) to store user information in a rule entry of a rule set.

%CHANGE uidmask1,uidmask2,...,uidmaskn

Indicates who, besides the security administrator, can replace or delete any part of a rule set. This statement identifies one or more UIDs that have this change authority. You can separate multiple UIDs or masks with commas or blank spaces.

For $ROLESET rules, specify %CHANGE logonid1, logonid2,…,logonidn. Each logonid need to be specified as a full, unmasked logonid.

A user designated by %CHANGE can further delegate the %CHANGE authority to other users. For activation or deactivation of the site's ability to use this control statement, see the description of the CHANGE field of the GSO RULEOPTS record in the CA ACF2 for z/OS Administrator Guide.

One way to delegate rule writing authority is to have the security administrator compile and store a rule set that contains only the $KEY, $TYPE, $SYSID, and %CHANGE control statements (that is, no rule entries). This lets him store a skeleton rule set and lets a designated user refine it, without the security administrator having to write any rule entries.

Important! Because you can modify a table's data using access through a view, you should control who can change view rule sets. You might decide not to use %CHANGE with view rule sets because they can inadvertently give the changer access to table data that the administrator of the view rule set did not intend.

%RCHANGE uidmask1,uidmask2,...,uidmaskn

Indicates which users have restricted change authority over this rule set. This statement identifies one or more UIDs or UID masks of users who can change individual rule entries but not control statements. This means that a user designated by %RCHANGE cannot further delegate change authority, nor can he delete the rule set.

For $ROLESET rules, specify %RCHANGE logonid1, logonid2,…,logonidn. Each logonid need to be specified as a full, unmasked logonid.

A user designated by both %RCHANGE and %CHANGE control statements is granted the %CHANGE authority. For activation or deactivation of the site's ability to use this control statement, see the description of the CHANGE field of the GSO RULEOPTS record in the CA ACF2 Administrator Guide.

Important! Because you can modify a table's data using access through a view, you should control who can change view rule sets. You might decide not to use %RCHANGE with view rule sets because they can inadvertently give the changer access to table data that the administrator of the view rule set did not intend.