search cancel

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


Article ID: 240119


Updated On:


ACF2 - z/OS


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-/      *VIO  RHFS-/etc
RHFS-/etc.Vendor.lrs.vmcf.ihsa.#.plugin                *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


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)


Release : 16.0

Component : ACF2 for z/OS


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

          SAF FASTAUTH return codes: 00000000/00000000/00000000    
          Exit with return code = 00      
          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.