Writing Rules › How Do You Specify CA ACF2 Option for DB2 Rules? › Rule Entries › Syntax › Parameters Describing the Environment

Parameters Describing the Environment

The following parameters describe the environment that a request must match for a rule to apply:

rsrcmask

Completes the name of the resource to be protected. Do not enclose the values for rsrcmask IN SINGLE QUOTES. You can use extended resource keys for any resource name if the resource name is qualified. Extended resource keys cannot be used if a qualified resource name was specified in the $KEY value of a resource rule.

Most resource rules with extended resource keys use the first qualifier of the resource name (or a resource name mask) as the $KEY value and specify the remainder of the resource name (or a resource name mask) in individual rule lines. For example, if the resource name is TEST.TESTNAME2, you could create the following resource rule:

$KEY(TEST) TYPE(TBL) SYSID(TEST)
TESTNAME2 UID(…) SERVICE(SELECT) ALLOW 
‑         UID(*) SERVICE(SELECT) PREVENT

UID(‑|uidmask)

Specifies the UID or UID mask of the user or groups of users this rule applies to. If omitted, the rule entry applies to all users of the system.

ROle(role)

Specifies the name of an X(ROL) record to indicate the users for whom this rule entry applies. If you specify ROLE(-), the entry applies to all users of the system. Masks other than ROLE(-) are not allowed in the ROLE parameter. All characters are treated as literal characters.

When a user logs onto the system, CA ACF2 builds their role table, The table contains a list of all the roles to which the user belongs. This list includes roles and groups of roles.

During access validation on a Roleset rule, the first role in the list is used for validation. If access is denied, the next role in the list is selected and validation is redriven. This process continues until access is allowed or the user’s list of roles is exhausted.

User(logonid)

Specifies a logonid to indicate the particular user for whom this rule entry applies. If you specify USER(-), the entry applies to all users of the system. Masks other than USER(-) are not allowed in the USER parameter. All characters are treated as literal characters.

If access is denied by a rule line that specifies USER then the access is denied. In this case, CA ACF2 will not re-drive validation with the next role in the user’s role list.

Note: UID, ROLE, and USER parameters are all mutually exclusive

SHIFT(shift)

Identifies the one‑ to eight‑character name of the shift record in the Infostorage database that defines the allowable time, day, or date for access under this rule. If omitted, any time, day, or date is valid. You cannot mask this field.

Do not enter more than one SHIFT parameter in a rule entry. To create new day and time combinations, insert a new shift record. See “SHIFT Setting: Shift and Zone Records,” in the CA ACF2 Administrator Guide.

Active(date)

Specifies the first date when an access can take place under this rule. You can specify this date as mm/dd/yy, yy/mm/dd, or dd/mm/yy. The DATE field of the GSO OPTS record determines this date format, as described in the CA ACF2 Administrator Guide. ACTIVE is only valid when you are running with a RULEOPTS option of RULELONG.

UNTIL(date)

Specifies the last date when an access can take place under this rule. You can specify this date as mm/dd/yy, yy/mm/dd, or dd/mm/yy. The DATE field of the GSO OPTS record determines this date format, as described in the CA ACF2 Administrator Guide.

Note: If you specify both ACTIVE and UNTIL, the value of ACTIVE must be the same as the UNTIL date or contain a date that falls before the UNTIL date.

FOR(days)

Specifies the number of days from the ACTIVE date for this rule entry when access is allowed. (If you did not specify the ACTIVE date, the active date for this rule entry is the date the rule was stored.) The minimum number that you can specify is zero (meaning today only); the maximum is 365. Caution is necessary in using the FOR parameter so that subsequent compiles of the rule do not extend the life of the rule entry beyond the intended data. For this reason, it is recommended that the UNTIL parameter be used instead of the FOR parameter.

SERVICE(keyword1,keyword2,...,keywordn)

Applies only to rules written for databases, application plans, packages, collections, tables (or views), functions, schemas, sequences, stored procedures, JAVA archive files, and distinct types. Because you can perform various functions with these resources, the SERVICE parameter identifies the type of function that a user must request for this rule entry to apply. You must specify at least one keyword. You can specify more than one keyword by separating them with commas or blanks.

Some privileges are grouped into authorities that let the security administrator grant one authority instead of several privileges.

The possible keywords that you can specify for each type of resource are shown in the chart below. Keywords in parentheses indicate the IBM DB2 keyword. CA ACF2 Option for DB2 accepts only the shortened version, which you cannot abbreviate or mask.

1ALL does not include the CA ACF2 Option for DB2 CREATE privilege required to create or drop views.

2Specifying ALL in the SERVICE parameter generates the list of privileges shown above except for the previously noted privileges. You can decompile the rule to see which privileges were included in the SERVICE specification.

3CREATE is not an IBM DB2 privilege for views. CA ACF2 Option for DB2 uses it as one of the checks to determine whether a user can create or drop views. See Creating Views in the Processing Security Information section of the “Comparing DB2 and CA ACF2 Option for DB2 Features,” chapter for more information about creating views.

COLUMN(column1,column2,...,columnn)

Applies only when using the SERVICE(UPDATE) or SERVICE (REFER) keywords for tables. The COLUMN parameter lets you control who can update or reference a column. It limits the privileges that the UPDATE or REFER privileges grant. You can limit access to one or more columns by separating them with commas or spaces. CA ACF2 Option for DB2 applies the first rule that contains the column that matches the actual request. For example, CA ACF2 Option for DB2 uses the following rule to validate update access to the SALARY and EXMPTION columns of the PERSONEL.PAYROLL table on the DB2 subsystem DSNP. This rule allows (but logs) every update access that a payroll clerk makes to these columns.

$KEY(PERSONEL.PAYROLL) TYPE(TBL)
$SYSID(DSNP)
 UID(***PAYCLK) SERVICE(UPDATE) COLUMN(SALARY,EXMPTION) LOG

This CA ACF2 Option for DB2 rule is equivalent to the following SQL GRANT statement:

GRANT UPDATE(SALARY,EXMPTION) ON TABLE PERSONEL.PAYROLL TO PAYCLK

If you specify more than one column, CA ACF2 Option for DB2 validates each column one at a time. If you specify a column in two different rule entries, CA ACF2 Option for DB2 uses the first rule entry that matches the column that the user is requesting.

DATA(text)

Specifies up to 64 characters of data for your own use. This data is passed to the site exits and back to the calling application subsystem with the global $USERDATA control statement. This data could indicate further checking or contain some control information.

NEXTKEY(nextkey)

Specifies the key of an alternate rule set that CA ACF2 Option for DB2 checks if access to this resource is denied based on this rule entry. CA ACF2 only checks the NEXTKEY parameter when the access matches the environment criteria, but the rule line prevents the access. Validation of the access continues with the evaluation of the alternate resource rule set. See the “Use of NEXTKEY in Resource Rules” for more information about the use of NEXTKEY.