Re: ADRNAPF was IEBCOP Y losing APF authori sation i n mi ddle of JOB - etc
On 20 April 2010 19:09, Sam Siegel wrote: > With all of the discussion about APF and loading programs from various types > of libraries, I'm hoping someone can provide some clarification for > me regarding the ADRNAPF of the load macro. > > The doc indicates that a module can be loaded from a non-apf library > when ADRNAPF is used from an authorized program in supervisor state. The > doc further states that the it is the loading programs responsibility to > ensure that program loaded from the non-apf library receives control in > problem state. > > Please confirm that when the non-apf program receives control in problem > state, it cannot change to supervisor state, discounting the possibility of > using a magic svc, etc. How do you propose to pass control to your newly loaded code in problem state? If you just MODESET to problem state and BALR, then presumably the called program could issue a MODESET back to supervisor state, just like any other code running in an APF authorized job step. If not, then one must assume that the jobstep has lost APF authorization, and that seems most unlikely in this context. If you use SYNCH or ATTACH with JSTCB=YES, then you're in a whole different world, but System Integrity is still very much your responsibility. Be careful. Tony H. -- 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
Re: ADRNAPF was IEBCOP Y losing APF authori sation i n mi ddle of JOB - etc
On Tue, Apr 20, 2010 at 6:09 PM, Sam Siegel wrote: > With all of the discussion about APF and loading programs from various > types > of libraries, I'm hoping someone can provide some clarification for > me regarding the ADRNAPF of the load macro. > > The doc indicates that a module can be loaded from a non-apf library > when ADRNAPF is used from an authorized program in supervisor state. The > doc further states that the it is the loading programs responsibility to > ensure that program loaded from the non-apf library receives control in > problem state. > > Please confirm that when the non-apf program receives control in problem > state, it cannot change to supervisor state, discounting the possibility of > using a magic svc, etc. > the point of ADRNAPF is to allow supervisor state system functions like (say) the initiator or IMS to load garden variety programs from garden variety load libraries without jumping through hoops. That almost certainly existed (undocumented) for a long time and then at some point somebody probably said "oh that would probably be a useful function for ISVs too" and added the macro documentation to allow access to it. The warning about the loading program's responsibility for maintaining integrity should be fairly obvious. System components can be relied upon NOT to allow the loaded program to get control in a privileged condition. Anyone else that uses those functions has to follow the same rules. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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
Re: ADRNAPF was IEBCOP Y losing APF authori sation i n mi ddle of JOB - etc
On Wed, Apr 21, 2010 at 12:46 AM, Tony Harminc wrote: > On 20 April 2010 19:09, Sam Siegel wrote: > > > With all of the discussion about APF and loading programs from various > types > > of libraries, I'm hoping someone can provide some clarification for > > me regarding the ADRNAPF of the load macro. > > > > The doc indicates that a module can be loaded from a non-apf library > > when ADRNAPF is used from an authorized program in supervisor state. The > > doc further states that the it is the loading programs responsibility to > > ensure that program loaded from the non-apf library receives control in > > problem state. > > > > Please confirm that when the non-apf program receives control in problem > > state, it cannot change to supervisor state, discounting the possibility > of > > using a magic svc, etc. > > How do you propose to pass control to your newly loaded code in > problem state? If you just MODESET to problem state and BALR, then > presumably the called program could issue a MODESET back to supervisor > state, just like any other code running in an APF authorized job step. > If not, then one must assume that the jobstep has lost APF > authorization, and that seems most unlikely in this context. > > If you use SYNCH or ATTACH with JSTCB=YES, then you're in a whole > different world, but System Integrity is still very much your > responsibility. > Toni, I was going to use SYNCH(X). ATTACH(X) does not make sense for this design. Thanks, Sam > > Be careful. > > Tony H. > > -- > 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
