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
