Correct; anything you use Contents Supervision on.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Joel C. Ewing <jcew...@acm.org> Sent: Monday, February 18, 2019 4:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RACF: Limiting update-authorization of a file to a particular application And I forgot to mention, in addition to statically allocated STEPLIB, for TSO/ISPF I believe you also need to include static ISPLLIB allocations. Joel C Ewing On 2/18/19 11:37 AM, Seymour J Metz wrote: > PADS was and is easy to get wrong, which is why I advised the OP to read the > documentation carefully. The rules apply not just to datasets in the JCL but > also to datasets that you allocate dynamically. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of > Joel C. Ewing <jcew...@acm.org> > Sent: Sunday, February 17, 2019 5:43 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [SPAM] Re: RACF: Limiting update-authorization of a file to a > particular application > > Unless things have changed, in order for RACF program-controlled dataset > access to work, all programs loaded into the address space must be > covered by a RACF PROGRAM profile. > Typically one sets up a profile that will cover all modules in all > system datasets that might be loaded in the TSO environment -- for example a > PROGRAM ** profile with UACC(READ) with many group members of the form > "datasetname//NOPADCHK" > for each datasetname in the Linklist and each datasetname in the STEPLIB > of installation-defined TSO logon PROCs from which a load module might > be loaded into the TSO address space. These must all be libraries that > the normal TSO users cannot modify, as you are implicitly saying all the > programs in all these libraries can be trusted to not do anything > nefarious, so that when PROG1 opens the WHEN-restricted dataset, you > don't have to worry that you might also be allowing one of the other > programs also in memory that shouldn't have access to that dataset to > have access. Note that the PROGRAM ** profile must be appropriately > modified whenever the names of datasets in link list or STEPLIBs in TSO > logon procs change. > > I think you may then have to also set up a specific PROGRAM profile for > "PROG1" as well, but it would only need a group member for the actual > dataset that contains PROG1 > > RACF PROGRAM profiles are kept in memory, so any changes to PROGRAM > profiles requires a RACF REFRESH before changes take effect. > > If a TSO user explicitly loads a program from one of his own libraries > so that it is not covered by a PROGRAM profile, that will break the > program-controlled environment (and you want it to), and the user will > have to logoff and logon to restore a program-controlled environment. > > Putting PROG1 in the AUTHPGM list for TSO says it may run "authorized" > and use restricted and dangerous Operating System functions (is this > something you really want for a COBOL program?) and has nothing to do > with whether a program-controlled environment for RACF > Program-Controlled dataset access is maintained. > Joel C. Ewing > > On 2/17/19 10:05 AM, Steff Gladstone wrote: >> Ok. We have been playing around with program control. If PROG1 (a COBOL >> program incidentally) is to be allowed exclusively to update file MY.FILE, >> then we: >> >> 1. introduced PROG1 into the list of programs in AUTHPGM in member IKJEFT00 >> 2. Executed command RDEFINE for the file (and additionally for the LE >> runtime libraries - not sure if necessary) and PERMIT 'MY.FILE' >> WHEN(PROGRAM(PROG1)). >> >> The results were: >> >> 1. Executing PGM=PROG1 in batch -> good results >> >> 2. Executing a REXX procedure under PGM=IKJEFT01 in batch -> good results >> (when invoked either by CALL 'lib(PROG1)' or SELECT PGM(PROG1) >> >> 3. Executing a REXX procedure in TSO foreground invoking program with >> CALL 'lib(PROG1)' -> receives the following error: >> >> ISPS118L Service not invoked. A valid ISPF environment does not exist. >> >> >> 4. Executing a REXX procedure in TSO foreground invoking program with >> SELECT PGM(PROG1) -> receives the following error: >> >> IKJEFTSR interface error >> Authorized program 'PROG1'. Return code=20 Reason code=40. >> >> Current dialog statement: >> SELECT PGM(PROG1) >> >> We gather that we are running into the "dirty bit" problem that has been >> documented in various forums. What can we do to get around this (we need >> the program control feature under TSO foreground as well)? >> >> Thanks in advance, >> Steff Gladstone >> >> On Thu, 7 Feb 2019 at 18:06, Seymour J Metz <sme...@gmu.edu> wrote: >> >>> Program control, but pay close attention to the restrictions. >>> >>> >>> -- >>> Shmuel (Seymour J.) Metz >>> http://mason.gmu.edu/~smetz3 >>> >>> ________________________________________ >>> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf >>> of Steff Gladstone <steff.gladst...@gmail.com> >>> Sent: Thursday, February 7, 2019 6:37 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: RACF: Limiting update-authorization of a file to a particular >>> application >>> >>> Greetings, >>> >>> >>> >>> We have an TSO application for end-users that allows them to update certain >>> VSAM and PDS files. In order for them to update these files we of course >>> have to give their users update-authorization under RACF for those files. >>> >>> >>> >>> We want to limit their ability to update the files only via the particular >>> TSO application (or via a particular I/O routine used by the application) >>> and not via any other application program or IBM utility (e.g., IEBCOPY, >>> ISPF on-line edit or utilities, etc.). >>> >>> >>> >>> How can we define the RACF authorizations in such a way as to limit the >>> end-users' update capabilities to the application (or to a particular I/O >>> routine) alone? Would the same (or similar) definitions work for a site >>> using Top Secret instead of RACF? >>> >>> >>> >>> Thank you in advance, >>> Steff Gladstone >>> > -- > Joel C. Ewing > -- Joel C. Ewing ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
