An authorized program may have be written under the assumption that it is the EXEC PGM= program in a step, and thus that various kinds of system initiated cleanup will happen immediately when it terminates.
Consider, for example, an authorized program which creates PC routines. It may be assuming that it is the Cross Memory Resource Owning task in the address space, so that when it terminates, the system will disconnect the entry tables that the program connected, preventing subsequent PCs into the address space. If you were to put this program into AUTHPGM, a TSO user could invoke it via the CALL command, and after it terminated, other address spaces could continue to PC to it, and the storage to which the entry table points may now contain programs which were subsequently loaded by the untrusted TSO user. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" <IBM-MAIN@LISTSERV.UA.EDU> wrote on 11/17/2019 09:06:08 PM: > From: "Walt Farrell" <walt.farr...@gmail.com> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 11/18/2019 01:12 PM > Subject: Re: AUTHPGM in IKJTSOxx > Sent by: "IBM Mainframe Discussion List" <IBM-MAIN@LISTSERV.UA.EDU> > So the user is going to have to be more clever than that to pass an > address of some code that can cause a problem, while still getting > the program invoked with authorization. > > But as it can probably be done somehow, the idea of having a program > like that was unwise from the beginning. I'll have to think about > some other things that an authorized program running under TSO might > have to account for that it wouldn't in another environment. > > -- > Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
