I just upgrade from CA ACF2 r15 to r16 and now I am getting RDATALIB violations for a virtual keyring, how do I address these violations?

Products

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

Issue/Introduction

I just upgrade from CA ACF2 r15 to r16 and now I am getting RDATALIB violations for a virtual keyring, how do I address these violations?

Environment

Release:
Component: ACF2MS

Resolution

There was a change made to the R_datalib service resource checking in r16. It impacts sites that use virtual keyrings and have enabled the RDATALIB resource class in order to do granular resource checking (as opposed to global resource checks that rely on FACILITY class rules). 

The virtual keyring support allows three different mechanisms to retrieve CERTAUTH certificates. You can specify the keyring name in any of the following formats: 

*AUTH*/*
*SITE*/*
CERTAUTH/*
irrcerta/* 

In r15 the portion of the keyring name before the '/' is used as the high level qualifier of the RDATALIB entity meaning three different entity values might get validated: 

'*AUTH*.IRR_VIRTUAL_KEYRING.LST
'*SITE*.IRR_VIRTUAL_KEYRING.LST
CERTAUTH.IRR_VIRTUAL_KEYRING.LST
IRRCERTA.IRR_VIRTUAL_KEYRING.LST 

In r16 the high level qualifier of the RDATALIB entity will always be CERTAUTH, regardless of whether the virtual keyring specified *AUTH*, *SITE*, CERTAUTH, or irrcerta. This makes the resource check consistent -- i.e. you don't have to set up separate rules for *AUTH*, CERTAUTH and IRRCERTA on r16 since they all fall under the CERTAUTH high level qualifier. 

To address the violations any RDATALIB resource rules for a virtual Keyring should be updated with the new high level qualifier 'CERTAUTH' rather than '*AUTH* or 'IRRCERTA'. This change was a correction made in ACF2 r16 PTF RO89039.

For example:

$KEY(CERTAUTH.IRR_VIRTUAL_KEYRING.LST) TYPE(RDA)
 UID(serverUID) SERVICE(READ) ALLOW