What is the difference between the GSO PPGM record and the validation of programs via SAF FASTAUTH calls?
I plan to implement program validation and would like to know the difference between the GSO PPGM record and program validation that is done via SAF?
The following documents the differences between program validation via the GSO PPGM record and SAF:
- The GSO PPGM record contains a list of programs defined as protected. This record is used in conjunction with the PPGM bit in the user's LOGONID record.
If the program listed in the PPGM GSO record is specified on a JCL EXEC PGM= statement in a batch job then CA ACF2 will verify that the user has access to the program by checking the PPGM bit in the user's LOGONID record. If this bit is not set then CA ACF2 will deny access to the program. In this case, CA ACF2 will issue the following message: ACF9A913 UNAUTHORIZED USE OF A RESTRICTED PROGRAM. CA ACF2 will also write an SMF record that details the access environment. You can run the ACFRPTDS report with the PROGRAM option to review the violations.
CA ACF2 will also check the PPGM list when a dataset is opened. If a violation occurs due to a PPGM program being used and the user is not allowed to use it, the user will receive message ACF99913 with rc=20. In this case the program issuing the open will not be the same as the program on the EXEC PGM= statement.
The PPGM bit in the user's LOGONID record lets the user execute ANY program in the protected program list. I should note that the NON-CNCL privilege also allows the user to execute any program in the PPGM list. The following is an example of how to implement program security via the GSO PPGM record: In this example any program that begins with IFHD or FDR and program IEBGENER will be included in the PPGM list.
CHANGE PPGM PGM-MASK(IEBGENER, IFHD-, FDR-)
Note: Only users that have either NON-CNCL or the PPGM bit in their LOGONID record are permitted to use these programs.
- Program validation via SAF is done via SAF FASTAUTH security calls. It is issued by contents supervisor for EVERY program that is FETCHed with the program as the entity name and CLASS=PROGRAM. This validation uses resource rules to determine access to the program. Note that the resource rules are required to be resident for the validation to work correctly. Program validation via SAF is enabled by inserting the following SAFDEF record:
INSERT SAFDEF.PROGCHKX ID(PROGCHKX) MODE(GLOBAL) -
** Where PROGCHKX can be any meaningful identifier for this SAFDEF.
Other steps associated with enabling SAF security for Programs:
- Create a generic rule for type(PGM) to allow access ie.
- Create a specific rule for the program(s) to be protected ie.
- Add the type PGM resident via GSO INFODIR:
CHANGE INFODIR TYPES(R-RPGM)
- Do a Refresh command to make the INFODIR record effective:
- Do a Rebuild command to load the resident rules for type PGM:
- Do a Refresh command to make the SAFDEF effective:
**NOTE: FASTAUTH obtains rules from storage calls the resource rule interpreter. If access is allowed ACF2 will set an allow return code. If access is denied ACF2 will check the LOGONID record for the NON-CNCL privilege. If ACF2 grants access via the NON-CNCL privilege, then ACF2 will allow the access but log it. If access is denied, Contents Supervisor will issue the following messages and end the job with an S306-34 abend:
CSV026I MODULE xxxxxxxxx NOT ACCESSED, PROGRAM ACCESS DATA SET RESTRICTION
CSV028I ABEND306-34 JOBNAME=yyyyyyyyy STEPNAME=xxxxxxxx
Consult the CA-ACF2 Administration Guide, specifically the sections describing the GSO PPGM record and Securing DFSMS Programs.