Resource Rule Entry Environment checking in ACF2

Products

• ACF2
• ACF2 - z/OS
• ACF2 - MISC
• ACF2 - DB2 Option

Issue/Introduction

How does ACF2 select a resource rule entry? Is it different from dataset access rule entries?

Resolution

In order for an ACF2 resource rule entry to be selected, it must match the resource rule environment. This environment includes the following parameters:

• ACTIVE
• FOR
• RECCHECK
• RSRCMASK
• SERVICE
• SHIFT
• SOURCE
• SYSID
• UID
• UNTIL
• VERIFY

For example, if an ACF2 for Db2 resource rule is written like this to try give USER001 only SELECT access to TEST.TBLTEST.- resources, but SELECT and UPDATE access for any other TEST.- resource:

$KEY(TEST) TYPE(TBL) SYSID(ABCT)
 TBLTEST.- UID(******USER001) SERVICE(SELECT) ALLOW
 - UID(*) SERVICE(SELECT,UPDATE) ALLOW

ACF2 will not deny UPDATE access to USER001 for TEST.TBLTEST.ABC because SERVICE(UPDATE) does not match the first rule line. The second rule line will then be checked and because it is a match for RSRCMASK, UID, and SERVICE the user will be given UPDATE access for TEST.TBLTEST.ABC.

To deny USER001 UPDATE access to all TEST.TBLTEST.- resources, an additional PREVENT line would need to be added so the environment is matched before falling to the last rule line. In the following example, specifying SERVICE(ALL) will add all services automatically to the rule line. 

RECKEY TEST ADD( TBLTEST.- UID(******USER001) SERVICE(ALL) PREVENT) SYSID(ABCT)

$KEY(TEST) TYPE(TBL) SYSID(ABCT)
 TBLTEST.- UID(******USER001) SERVICE(SELECT) ALLOW
 TBLTEST.- UID(******USER001) SERVICE(ALTER,DELETE,INDEX,INSERT,SELECT,UPDATE,REFER,TRIGGER,UNLOAD) PREVENT
 - UID(*) SERVICE(SELECT,UPDATE) ALLOW

Now when USER001 attempts to UPDATE TEST.TBLTEST.ABC, they will be denied since the second rule line matches the environment.

This is different from the way ACF2 selects dataset access rule entries as the environment parameters for dataset access are not the same. The environment parameters for dataset access rule entries are as follows:

• ACTIVE
• DDNAME
• DSNMASK
• FOR
• LIBRARY
• PROGRAM
• SHIFT
• SOURCE
• SYSID
• VOLUME
• UID
• UNTIL

If USER001 only needs READ and EXECUTE access to dataset TEST.TESTDSET, the following rule can be written:

$KEY(TEST)
 TESTDSET UID(******USER001) READ(A) EXEC(A)
 - UID(*) READ(A) WRITE(A) EXEC(A)

When USER001 tries to get WRITE access to TEST.TESTDSET, they will be denied as the DSNMASK and UID match in the first rule entry and WRITE(A) is not specified in that entry. An additional entry with WRITE(P) or specifying WRITE(P) in the entry line is not necessary as the dataset access rule entry environment does not require a match on access permissions like the resource rule environment does with SERVICEs. If WRITE(A) is not specified in the rule entry, WRITE(P) is assumed and the user will be denied access.

Additional Information

For additional information in the ACF2 documentation regarding Resource Rule Entries: Resource Rule Entries

For additional information in the ACF2 documentation regarding Access Rule Entries: Access Rule Entries