On Fri, Apr 23, 2010 at 3:04 PM, Rob Scott <rsc...@rocketsoftware.com>wrote:
> >If this was true, would it be acceptable to turn the JSCBAUTH bit back on? > > No > > Take a (google) look through the archives of IBM-MAIN for discussions that > include any of the following keywords : > > JSCBAUTH > Magic SVCs > AUTHON SVCs > > JSCBAUTH flipping is a "no-no" - do not go there. > I will research those. Thanks. > > > > Rob Scott > Developer > Rocket Software > 275 Grove Street * Newton, MA 02466-2272 * USA > Tel: +1.617.614.2305 > Email: rsc...@rs.com > Web: www.rocketsoftware.com > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Sam Siegel > Sent: 23 April 2010 14:42 > To: IBM-MAIN@bama.ua.edu > Subject: Re: Calling unauthorized code from an authorized address space > > On Fri, Apr 23, 2010 at 1:05 PM, Peter Relson <rel...@us.ibm.com> wrote: > > > By definition, the subject seems to me to be an oxymoron. > > > > Yes ... I agree that the subject lines is not properly worded and is > technically incorrect ... I'm pretty sure that the intent was understood. :) > > > > > An authorized address space has JSCBAUTH on. There can be no > > unauthorized code running in such a situatino. > > Now, if you meant a space in which JSCBAUTH is not on (perhaps it was > > on) and there are tasks that are supervisor state and/or system key > > and you want to give control to code that is problem state user key, > > then you should be using SYNCH(X). You might choose to SYNCH(X) to > > "yourself" and do a LINK(X) from there, or a LOAD / CALL or whatever. > > As I mentioned in a post on the ADRNAPF topic, once JSCBAUTH has been > > turned off, you must never turn it back on. > > > > Yes ... SYNCH(X) this is what I'm doing after flipping the JSCBAUTH bit > off. I see your point about not turning it back on as the problem state > program may have ATTACHed new TCBs. If JSCBAUTH was turned back on then the > TCB(s) initiated by the problem state program will suddendly find > themselves in an authorized address space. > > Clearly this is a significant exposure. > > Now a question about TCB creation. After control is returned from the > problem state program to the caller, it should be possible to see if it > ATTACHed any new TCBs. If new TCBs were created, I could abend the entire > process instead of flipping the JSCBAUTH bit back on. This would ensure > that when the user exit returned to the caller, none of the problem state > program code was running. > > If this was true, would it be acceptable to turn the JSCBAUTH bit back on? > > > > > > > On a somewhat related note, although the cross-memory architecture > > supports authority-decreasing PCs, I believe it is the case that z/OS > > does not. It cannot stop you from creating them, but you should not be > > doing so. > > > > > > Actually I was considering PC routines for the more standard perspective. > Put all of the authorized code in a separate address space and then provide > a PC routine to transfer data from a problem state program initiated in the > normal EXEC PGM= fashion. > > Or use a DATA SPACE and provide access to the ALETs via name/token service. > > Pretty much everyones advice has been to find an alternate design that does > not require loading code from an authorized library and running it in an > authorized address space. > > I'm going to spend some time thinking about this to see how it can be done > and still accomplish the business objectives. > > All of the advice is sincerely appreciated and I will provide some > additional details this weekend in the hopes that I can get some more > feedback. > > Thanks > Sam > > > > > 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 > > ---------------------------------------------------------------------- > 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
