Hi, not sure if it is correct forum ...
I define program access to dataset (PADS) in RACF using class PROGRAM for pgm MYPGM and MYID RACF group. If MYPGM is running from MYLOAD pds, then MYID has UPDATE access to MYDSN. It worked until MYPGM call any LM services ( execio diskw worked fine - it updated MYDSN)... actualy LMINIT is working fine, but LMCOPY is not working... looks like RACF recognised that it is running not MYPGM , but IEBCOPY and not granted access to MYDSN - because it has UPDATE access only for MYPGM ( not for IEBCOPY ) ... I've tried to code MYPGM in REXX ( address ISPEXEC for LMCOPY ) and in PL/I ( call ISPLINK LMCOPY) - the same - no UPDATE access to MYDSN (RC=913) ... I need suggestion
Joined: 01 Sep 2006 Posts: 2547 Location: Silicon Valley
In the link that Enrico posted, it mentioned 'clean' and 'dirty' environments. But I did not see a definition of 'dirty'.
My recollection from 25 years ago was that any non-APF program contaminated the environment. You need to redesign your process to only do I/O within your program, without any outside calls. Perhaps call the program once to read and another time to write. Do any ISPF processing outside of your PADS program.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
Pedro, here's a definition from the RACF Security Administrators Guide manual, with emphasis added by me:
Quote:
Authorization checking for access control to load modules
z/OS V1R12.0 Security Server RACF Security Administrator's Guide
SA22-7683-14
When contents supervision invokes RACF® to authorize the loading of a module, RACF makes several checks. Some of these checks involve program-accessed data sets. For more information on program-accessed data sets, see Program access to data sets (PADS) in BASIC mode.
The checks that RACF makes when a user makes a request to load (execute) a program are:
If program control has been activated with SETROPTS WHEN(PROGRAM)
If program control is active, RACF checks to see whether the program is protected by a profile in the PROGRAM class
If the program is not protected, RACF determines whether there are any data sets currently open using PADS or whether there are any execute-controlled programs in storage in the address space.
If there are no such data sets or programs, RACF marks the environment dirty (uncontrolled) and allows the user to execute the program.
If there are data sets currently opened using PADS, or programs to which the user has only EXECUTE authority, RACF fails the request and the system abends the task. RACF issues message ICH423I to document the execute-controlled programs, or message ICH424I to document the PADS data sets that caused the operation to fail. In this way, RACF prevents uncontrolled programs from gaining access to protected data or programs inappropriately.
If the program is protected by a profile but the user does not have at least EXECUTE authority to the program, RACF causes the system to abend the task because the user is not authorized to execute the program.
If the program is protected by a profile and the user has only EXECUTE authority to the PROGRAM profile or to the library that contains the program (when the program is loaded from a JOBLIB, STEPLIB, or tasklib), and if the job step or TSO session is running in ENHANCED program security mode, RACF checks whether an appropriate program established the program environment. RACF determines if the first program executed in the job step had the 'MAIN' attribute, or (if necessary) if the program invoked by TSOEXEC or IKJEFTSR had the 'MAIN' attribute. If the program does not have MAIN, RACF next determines if the first program run in the current task (TCB) or the first program executed in some parent task had the 'BASIC' attribute. If so, RACF allows the request. Otherwise, RACF fails the request and issues message ICH429I to describe the problem and tell you what program established the environment.
If the user is still authorized to execute the program and the program was defined with the PADCHK attribute, RACF checks whether any program-accessed data sets are open.
If no program-accessed data sets are open, RACF allows the user to execute the program.
If program-accessed data sets are open, RACF checks the user and program combination to verify that the combination has at least the same authority to each data set in the list that was required when each data set was opened. For more information on the requirements, refer to Program access to data sets (PADS) in BASIC mode.
If the use or program combination has sufficient authority to all of the opened data sets, RACF allows the user to execute the program.
If the user or program combination does not have sufficient authority to all of the opened data sets, RACF causes the system to end the task (with abend code 306 or 806).
Note:
If you are denied access to a requested resource and you implemented program control (with or without PADS), RACF's messages should provide sufficient information to determine the problem. If not, refer to z/OS Security Server RACF Diagnosis Guide for additional help in determining the cause of the authorization failure.
