TSO is NOT a good example. The flipping in and out of authorization has been discussed ad infinitum. Pick something else for discussion points unless we are diverging into what's possible, and there are tons of inadvisable ways to break mvs integrity.
Rob Schramm On Mon, Jul 23, 2018, 9:47 PM Paul Gilmartin < [email protected]> wrote: > On Mon, 23 Jul 2018 22:53:59 +0000, Seymour J Metz wrote: > > >I hope not, and IBM will take an APAR if it's possible. The one exception > is that an unauthorized TSO command can ask the TMP to run an authorized > command (or service), but the TMP will set the unauthorized command > non-dispatchable for the duration. > > > More curious: > Suppose I use JCL DD, or SVC 99, or BPXWDYN to allocate DD=SYSIN, > FREE=CLOSE, DISP=DELETE. Then I JCL EXEC or TSO CALL an authorized > program which OPENs SYSIN for INPUT, READS, and CLOSES it. Will the > CLOSE free and delete it? Which component, at what point ensures that I > have RACF permission to delete that data set? > > Similar question for /bin/tso which supports "allocation requests"; > environment > variables containing strings eerily similar to BPXWDYN arguments. The Ref. > hints but doesn't directly say that /bin/tso invokes BPXWDYN to perform the > allocations. > > >________________________________________ > >From: essteam > >Sent: Monday, July 23, 2018 6:46 PM > > > >Im sure there is an Integrity exposure with these scenarios. > > > >1)Can a Problem Program (Key 8) attach a Surtask that is authorized ? > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- Rob Schramm ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
