I am sorry, I only mean to educate myself. You explain the behavior, IMHO, but you don't say why. OR you said why and I didn't get it.
Why can I not create a Rexx function that is authorized? (I do NOT want to, I'm just curious. I KNOW how to make it happen in various ways, some that violate system integrity, and some that don't). Lindy -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ray Overby Sent: Wednesday, December 29, 2010 12:13 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Authorized Rexx Assembler Function By architecture, REXX functions are executed in an environment where: - The psw key is 8 - The psw indicates problem state - The JSCBAUTH bit is zero. When the JSCBAUTH bit is zero the MODESET macro will get a S047 abend when executed. Therefore rexx functions cannot get into an authorized state using MODESET. This should eliminate the possibility of directly coding the authorized code in the rexx function unless you bypass z/OS system integrity. To get into an authorized state should require use of a SVC, a PC routine, or the IKJEFTSR TSO function. There are probably some items I am leaving out but you need to understand the environment the rexx functions get control in. That will dictate what options you have for doing something authorized. I hope this helps. On 12/28/2010 15:03 PM, Lindy Mayfield wrote: > How then? And why not? Or is that another stupid question of mine? > > But oh I know exactly what you mean in one context. It is trivial to write a > "command" that uses IKJCT441 to update Rexx variables and call it from a Rexx > program. > > Lindy > > ________________________________________ > From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf > Of Hayim Sokolsky [hsokol...@dtcc.com] > Sent: 28 December 2010 23:01 > To: IBM-MAIN@bama.ua.edu > Subject: Re: Authorized Rexx Assembler Function > > Lindy, > > The function is NOT invoked as COMMAND. Therefore it can't be APF. > > > Hayim > _____________________________________ > Hayim Sokolsky, CISSP > Mainframe Security Architect > DTCC Corporate Information Security > 18301 Bermuda Green Dr, MS 1-CIS > Tampa FL 33647-1760 > > Tel. (813) 470-2177 > > IBM Mainframe Discussion List<IBM-MAIN@bama.ua.edu> wrote on > 2010.12.28 > 15:34:48: > >> Thank you, Hayim. That makes sense. >> >> I guess the even shorter version is that if it isn't in IKJTSOxx it >> won't run authorized. >> >> It doesn't, at least to me yet, explain why a Rexx assembler >> function, even if it meets all the criteria of a TSO command, APF, in >> IKJTSOxx, that it won't run authorized. >> >> Lindy >> ________________________________________ >> From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf >> Of Hayim Sokolsky [hsokol...@dtcc.com] >> Sent: 28 December 2010 22:18 >> To: IBM-MAIN@bama.ua.edu >> Subject: Re: Authorized Rexx Assembler Function >> >> The short version goes like this, at least it used to work this way. >> It probably still does. >> >> IKJEFT01 (the "READY" prompt) is authorized. For every command that >> is run, it attaches IKJEFT02 to process the command. IKJEFT02 in turn > checks >> to see if the command being run is in the authorized command list in >> IKJTSOxx. If it is, it directly attaches the command, which is still >> authorized. If it is not in the table, it attaches IKJEFT09 to attach > the >> command. IKJEFT09 is unauthorized, and therefore the command can not >> be authorized. >> >> IKJEFT01 (authorized) >> --attach--> IKJEFT02 (authorized) >> --attach--> command (authorized) >> >> IKJEFT01 (authorized) >> --attach--> IKJEFT02 (authorized) >> --attach--> IKJEFT09 (non-authorized) >> --attach--> command (non-authorized) >> >> >> >> Hayim >> _____________________________________ >> Hayim Sokolsky, CISSP >> Mainframe Security Architect >> DTCC Corporate Information Security >> 18301 Bermuda Green Dr, MS 1-CIS >> Tampa FL 33647-1760 >> >> Tel. (813) 470-2177 >> >> IBM Mainframe Discussion List<IBM-MAIN@bama.ua.edu> wrote on >> 2010.12.28 >> 14:51:07: >> >>> By asking these questions, I'm only curious, learning, and want to >>> know as much about z/OS as I can. Having said that... >>> >>> What exactly happens to cause an authorized Rexx assembler function >>> to be un-authorized, even if AC(1) and run from an authorized >>> library? Do you mainipulate the JSCBAUTH? Do you somehow mark the >>> library as unathorized? (or is that the same thing?) Or is this >>> simply a part of TSO? Then why not let me simply add it to the >> IKJTSOxx? >>> (I realize that some or all of the above shows a lack of knowledge >>> about TSO and authorized "stuff".) >>> >>> And if you know, why was it designed this way? >>> >>> Thank you! >>> Lindy >>> >>> ________________________________________ >>> From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf >>> Of Peter Relson [rel...@us.ibm.com] >>> Sent: 23 December 2010 16:00 >>> To: IBM-MAIN@bama.ua.edu >>> Subject: Re: Authorized Rexx Assembler Function >>> >>>> Call an SVC that flips the JSCBAUTH bit back on. >>> DO NOT DO THIS. In the general case there is no way to do this >>> without introducing system integrity problems. >>> >>> And also do not use an SVC to return control to an unauthorized >>> caller >> in >>> an authorized state. >>> >>> Peter Relson >>> z/OS Core Technology Design >>> >>> -------------------------------------------------------------------- >>> -- For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN >>> INFO Search the archives at >>> http://bama.ua.edu/archives/ibm-main.html >>> >>> -------------------------------------------------------------------- >>> -- For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN >>> INFO Search the archives at >>> http://bama.ua.edu/archives/ibm-main.html >> >> <BR>_____________________________________________________________ >> <FONT size=2><BR> >> DTCC DISCLAIMER: This email and any files transmitted with it are >> confidential and intended solely for the use of the individual or >> entity to whom they are addressed. If you have received this email in >> error, please notify us immediately and delete the email and any >> attachments from your system. The recipient should check this email >> and any attachments for the presence of viruses. The company accepts >> no liability for any damage caused by any virus transmitted by this >> email.</FONT> >> >> --------------------------------------------------------------------- >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN >> INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html >> >> --------------------------------------------------------------------- >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN >> INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
