Unexpected behavior with HFSSEC rules and Symbolic links after deleting ACF2 rules

Products

• ACF2 - z/OS

Issue/Introduction

symbolic links in OMVS for unix directories.
For Example:

lib -> $VERSION/lib

etc -> $SYSNAME/etc

bin -> $VERSION/bin

 

Rules existed for both $KEY(/etc) and $KEY(/SYS1)

 

Someone accessing /etc would actually be accessing /SYS1/etc (on LPAR SYS1).
This would be hitting $KEY(/SYS1) and should not be using the $KEY(/etc) rule. 

When $KEY(/etc) TYPE(HFS) was deleted violations occurred for these resources.

RHFS-/etc.Vendor.xxx.ssssss.vvvv.bbb.hhhh      *VIO  RHFS-/etc

RHFS-/etc.Vendor.xxx.ssssss.vvvv.bbb.hhhh       *VIO  RHFS-/etc  

 

When displaying the symbolic link it appeared as though the link information was no longer available

 

 

lrwxrwxrwx     1 BPXOINIT OSS           12 Jun 16  2015 etc -> $SYSNAME/etc

However after deleting the $KEY(/etc) the link looks like this.
lrwxrwxrwx     1 BPXOINIT OSS           12 Jun 16  2015 etc

 

 

Environment

Release : 16.0

Component : ACF2 for z/OS

Cause

The ACF2 Manual states:

When an actual file is accessed via a symbolic link, the file name passed to ACF2 has been resolved to the
actual file name of the file and validation is done based on that actual file name.
For most validation situations this is sufficient.
However, in the case of the following, ACF2 validates the link itself rather than the file name:

unlink (delete a symbolic link)

rename (change one symbolic link name to another)

readlink (read a symbolic link to determine what it points to)

lchown (change the owner of a link)

Resolution

an HFS sectrace showed that when opening a directory  a readlink event occurs.
The readlink requires access to the $KEY(/etc) per above documentation.

 CAS2319I TRACEID=HFS   USER=USER01  JOBNAME=USER01      
          EVENT=opendir                                            
          /                                                        
          READ                                                     
          /                                                        
          SAF FASTAUTH return codes: 00000000/00000000/00000000    
          Exit with return code = 00      
                        
 CAS2319I TRACEID=HFS   USER=USER01  JOBNAME=USER01 620       
          EVENT=readlink                                           
          /etc                                                     
          READ                                                     
          /ETC                                                     
          SAF FASTAUTH return codes: 00000008/00000008/00000000    
          Exit with return code = 08                               
 CAS2312E USER01  - READ    ACCESS DENIED 621                     

This proves that the problem relates to the READLINK event requiring the $KEY(/etc) resource rule.
Access is required to both the link name and the symbolic that it points to.

Without access to the link name you cannot point to the symbolic.
That is why the symbolic link looked like data had been removed when the rule was deleted.