CA OPS/MVS - ACF2 Violation When Auto-Enabling a Rule
Article ID: 129584
Updated On:
Products
OPS/MVS Event Management & Automation
Issue/Introduction
The client received an ACF2 violation, ACF99913, when attempting to auto-enable a rule:
OPSMAIN ACF99913 ACF2 VIOLATION-04,00,BPXOINIT,OPSMB1,SYS2.OPSMVS.QUAL.STATEMAN.RULES,N/A
OPSMAIN IEF196I ACF99913 ACF2 VIOLATION-04,00,BPXOINIT,OPSMB1,
OPSMAIN IEF196I SYS2.OPSMVS.QUAL.STATEMAN.RULES,N/A
OPSMAIN ACF90913 -DATASET CANNOT BE OPENED; AUTHORIZATION IS REQUIRED.
OPSMAIN IEF196I ACF90913 -DATASET CANNOT BE OPENED; AUTHORIZATION IS REQUIRED.
Why was there a security violation for OPS before the recycle and not after?
OPSMAIN ACF99913 ACF2 VIOLATION-04,00,BPXOINIT,OPSMB1,SYS2.OPSMVS.QUAL.STATEMAN.RULES,N/A
OPSMAIN IEF196I ACF99913 ACF2 VIOLATION-04,00,BPXOINIT,OPSMB1,
OPSMAIN IEF196I SYS2.OPSMVS.QUAL.STATEMAN.RULES,N/A
OPSMAIN ACF90913 -DATASET CANNOT BE OPENED; AUTHORIZATION IS REQUIRED.
OPSMAIN IEF196I ACF90913 -DATASET CANNOT BE OPENED; AUTHORIZATION IS REQUIRED.
Why was there a security violation for OPS before the recycle and not after?
Environment
CA OPS/MVS
Resolution
Changing the EUID, using SuperUser authority, is designed to be a temporary exercise.
From IBM documentation on switching in and out of superuser authority:
. This activity should not be done in a multiprocess address space (which is what OPSMAIN is).
. Also, there is a 'rotation' of UID values when switching between the UID, the effective UID (EUID), and the real UID.
. This is why the UserID of the ASID in which this occurs does not change upon the first switch of a UID.
. If superuser authority is needed in a piece of automation, the switch/change should be done in an OSF/USS server ASID (to isolate OPSMAIN).
. If switching/changing the UID/EUID, the change should be reverted to what the values were before the change was needed, in the same piece of executing code.
Reference doc URL:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxb200/swit.htm
The client will find all occurrences of this changing/switching of the UID in their automation, and ensure that the UID is changed back to the necessary value and/or move the automation, so that the code is not executing in the OPSMAIN ASID.
From IBM documentation on switching in and out of superuser authority:
. This activity should not be done in a multiprocess address space (which is what OPSMAIN is).
. Also, there is a 'rotation' of UID values when switching between the UID, the effective UID (EUID), and the real UID.
. This is why the UserID of the ASID in which this occurs does not change upon the first switch of a UID.
. If superuser authority is needed in a piece of automation, the switch/change should be done in an OSF/USS server ASID (to isolate OPSMAIN).
. If switching/changing the UID/EUID, the change should be reverted to what the values were before the change was needed, in the same piece of executing code.
Reference doc URL:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxb200/swit.htm
The client will find all occurrences of this changing/switching of the UID in their automation, and ensure that the UID is changed back to the necessary value and/or move the automation, so that the code is not executing in the OPSMAIN ASID.
Feedback
Yes
No
Powered by
