Using the term "RACF-authorized" is incorrect in this context. All modules loaded in the address space must be program-controlled (not authorized), which means they must be covered by a PROGRAM profile that includes a group member for the dataset from which they were loaded. The fact that a module is program-controlled does not give that module any additional authority -- it just means that the address space is not made "dirty" by loading that module into the address space because it comes from a "trusted library". Nor does this concept have anything to do with whether a program runs in z/OS "authorized" state. If and only if the address space is not "dirty" in the sense of RACF program control, a currently running program may be granted program-controlled access to a dataset via a RACF DATASET profile with a WHEN clause for that program
Having the program in question running under a new TCB with its own TASKLIB doesn't affect the rules for PROGRAM profiles, because once the dataset is opened, data could potentially be accessed from other programs running under a different TCB in the same address space, or the TCB running the program could execute code from any module loaded in the same address space. All modules loaded in the address space must come from trusted libraries, and that is essentially what is enforced by the PROGRAM profile coverage requirement for all modules loaded in the address space. PROGRAM profiles may also be used to restrict someone from loading/executing a specific module from a specific library, but that is a totally different usage motivation than what is being discussed here. Joel C. Ewing On 2/20/19 7:51 AM, Steff Gladstone wrote: > Do I understand correctly that TSOEXEC CALL creates a new subtask > environment which is "insulated" from the goings-on in the mother task? > Would specifying TASKLIB further ensure that only those modules > loaded/linked/attached from the TASKLIB library need be RACF-authorized? > > Or is there something I am missing? > > On Mon, 18 Feb 2019 at 16:48, Walt Farrell <[email protected]> wrote: > >> On Sun, 17 Feb 2019 18:05:59 +0200, Steff Gladstone < >> [email protected]> 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 >> >> Unless the program is linkedited with AC(1) and needs to run authorized >> (most COBOL programs don't) I don't see a reason to put it in AUTHPGM. >> >> You will likely run into problems in a TSO environment with the >> environment being marked dirty, as you noted. >> >> Your best hope to avoid that is to make sure you've followed the >> instructions in the RACF Security Administrators Guide about defining the >> PROGRAM ** profie and all the libraries that you should specify for its >> ADDMEM operand. Make sure you use the specified UACC value, too. >> >> If that doesn't work, then your next approach would be to try TSOEXEC CALL >> ... to invoke the program. >> >> Really, all of this is explained in the Security Administrators Guide in >> the sections on Program Control and Program Access to Data (PADS), along >> with some examples and recommendations. As getting this working under TSO >> is very difficult, my best recommendation is to read those sections and >> follow the instructions exactly. >> >> -- >> Walt >> >> ... >> -- Joel C. Ewing ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
