A dataset access rule has a rule entry with READ(ALLOW) EXEC(PREVENT) coded, however when compiled and stored, the ACF70050 warning message is issued and the rule entry is changed to READ(ALLOW) EXEC(ALLOW), why?

Products

• ACF2
• ACF2 - DB2 Option
• ACF2 for zVM
• ACF2 - z/OS
• ACF2 - MISC
• PanApt
• PanAudit

Issue/Introduction

The Execute(Allow|Log|Prevent) access permission will be set to the specified value, or the value of the Read(Allow|Log|Prevent) permission, whichever is more permissive.

 

 

Environment

Release:
Component: ACF2MS

Resolution

The following is an example of a dataset access rule to be compiled.

$KEY(SYSA)
 TEST.LOADLIB UID(-) R(A) E(P)

When this rule is compiled, the following ACF70050 warning message will be issued and the Execute access permission will changed from Execute(PREVENT) E(P) to Execute(ALLOW) E(A) because the Read access permission of ALLOW is more permissive.

ACF70050 IN ONE OR MORE RULES, THE EXECUTE ACCESS WAS SET TO THE READ ACCESS

The compiled rule will be changed to:

$KEY(SYSA) 
 TEST.LOADLIB UID(*) READ(A) EXEC(A)

Note that the EXEC access permission CAN be more permissive that the READ access permission. For example, a rule entry with READ(PREVENT) EXEC(ALLOW) can be coded:

$key(sysa) 
 TEST.LOADLIB UID(-) R(P) E(A)

After compiling this rule, the rule entry will retain the Read(PREVENT) R(P) and Execute(ALLOW) E(A).

 

Additional Information

Details on the dataset access permissions can be found in the ACF2 Administrator Guide in Chapter 6: Maintaining Access Rules section "Rule Entry Syntax".