Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

RACF PADS

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> TSO/ISPF
View previous topic :: :: View next topic  
Author Message
anatol

Active User


Joined: 20 May 2010
Posts: 106
Location: canada

PostPosted: Fri Mar 22, 2013 6:24 pm    Post subject: RACF PADS
Reply with quote

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
Back to top
View user's profile Send private message

enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10292
Location: italy

PostPosted: Fri Mar 22, 2013 6:42 pm    Post subject: Reply to: RACF PADS
Reply with quote

did You check here
http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.icha700%2Fpadsec.htm

and the parent topic
Protecting Programs
Back to top
View user's profile Send private message
anatol

Active User


Joined: 20 May 2010
Posts: 106
Location: canada

PostPosted: Fri Mar 22, 2013 8:50 pm    Post subject: Reply to: RACF PADS
Reply with quote

yes, I even printed this yesterday... read all, but still no clue ...
Back to top
View user's profile Send private message
Pedro

Senior Member


Joined: 01 Sep 2006
Posts: 2068
Location: Silicon Valley

PostPosted: Fri Mar 22, 2013 11:46 pm    Post subject: Reply to: RACF PADS
Reply with quote

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.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8132
Location: East Dubuque, Illinois, USA

PostPosted: Sat Mar 23, 2013 12:12 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> TSO/ISPF All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts find RACF group for access to spooled... jzhardy JCL & VSAM 1 Mon May 08, 2017 11:46 am
No new posts Liberty Angel Server using RACF Keyring martin9 CICS 0 Tue May 02, 2017 5:49 pm
No new posts RACF profile access vasanthz All Other Mainframe Topics 11 Fri Sep 23, 2016 5:51 am
No new posts RACF Easytrieve Plus macro Susan Jackson CA Products 0 Fri Jun 03, 2016 8:25 pm
No new posts Urgently Require RACF ACF2 Resource t... swapna bommarajupet Mainframe Jobs 0 Tue Sep 16, 2014 8:55 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us