Re: IEBCOPY losing APF authorisation in middle of JOB - etc
On 20 April 2010 19:16, Paul Gilmartin wrote: > I was envisioning that, as with LINKLIST, a load module loaded > from an authorized catenand would run authorized; a load module > loaded from an unauthorized catenand would run unauthorized. > No security problem. Should have been easy to do, given that > Jim M. says this determined by a bit in the DEB set at OPEN, > and OPEN surely knows what data set the DEB belongs to. But there's only one DEB for the whole concatenation. And the magic flag isn't in the section that represents each concatenation, though I suppose it could be. > But, Jim says (and I agree, as stated above) that there's > minimal value in mixing authorized and authorized data sets in STEPLIB. There might be a wee bit of an argument for doing it for JOBLIB, but still not enough to put in the effort. 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: IEBCOPY losing APF authorisation in middle of JOB - etc
On Tue, 20 Apr 2010 15:36:30 -0500, Rick Fochtman wrote: > > >>>From:Peter Nuttall >>>Date:Tue, 20 Apr 2010 07:48:46 +0200 >>> >>>Yes to all of that Puzzled me too ... Never seen it before I am >>>aware of the concatenation restriction on APF authorised load libraries >>>(and the integrity reasoning behind it), but there are no steplibs in the >>>job and the Joblib is, obviously, the same for all steps. >>> >>> >>> >>What is that "integrity reasoning"? Doesn't LINKLIST nowadays support >>a mixture of authorized and unauthorized libraries, with the authorization >>of the step depending on the status of the individual data set from >>which the module was loaded? >> >>Is it merely that since the programmer controls the content of STEPLIB >>there's little utility in supporting similar behavior in STEPLIB? >> >>-- gil >> >> >-- >I suspect that it's based on the premise that the LINKLIST libraries are >controlled by a security-conscious Systems Programming staff, whereas >STEPLIB can access any loadlib, including, perhaps, a library with >modules of "malicious intent or design". > ??? It can do that now; they just better not be authorized (unless they're GIMSMP). I was envisioning that, as with LINKLIST, a load module loaded from an authorized catenand would run authorized; a load module loaded from an unauthorized catenand would run unauthorized. No security problem. Should have been easy to do, given that Jim M. says this determined by a bit in the DEB set at OPEN, and OPEN surely knows what data set the DEB belongs to. But, Jim says (and I agree, as stated above) that there's minimal value in mixing authorized and authorized data sets in STEPLIB. -- gil -- 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: IEBCOPY losing APF authorisation in middle of JOB - etc
From: Peter Nuttall Date: Tue, 20 Apr 2010 07:48:46 +0200 Yes to all of that Puzzled me too ... Never seen it before I am aware of the concatenation restriction on APF authorised load libraries (and the integrity reasoning behind it), but there are no steplibs in the job and the Joblib is, obviously, the same for all steps. What is that "integrity reasoning"? Doesn't LINKLIST nowadays support a mixture of authorized and unauthorized libraries, with the authorization of the step depending on the status of the individual data set from which the module was loaded? Is it merely that since the programmer controls the content of STEPLIB there's little utility in supporting similar behavior in STEPLIB? -- gil -- I suspect that it's based on the premise that the LINKLIST libraries are controlled by a security-conscious Systems Programming staff, whereas STEPLIB can access any loadlib, including, perhaps, a library with modules of "malicious intent or design". Rick -- 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: IEBCOPY losing APF authorisation in middle of JOB - etc
IBM Mainframe Discussion List wrote on 04/20/2010 07:24:56 AM: > > Yes to all of that Puzzled me too ... Never seen it before I am > > aware of the concatenation restriction on APF authorised load libraries > > (and the integrity reasoning behind it), but there are no steplibs in the > > job and the Joblib is, obviously, the same for all steps. > > > What is that "integrity reasoning"? Doesn't LINKLIST nowadays support > a mixture of authorized and unauthorized libraries, with the authorization > of the step depending on the status of the individual data set from > which the module was loaded? > > Is it merely that since the programmer controls the content of STEPLIB > there's little utility in supporting similar behavior in STEPLIB? For an ordinary concatenation, contents supervisor knows only whether the entire concatenation is authorized, via a bit in the DEB which is set by OPEN processing. For LNKLST, contents supervisor built the concatenation and did the OPEN, so it can be aware of the authorization separately for each data set. The isn't much value in having that granularity for STEPLIB, since an authorized jobstep can't load anything from an unauthorized library. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: IEBCOPY losing APF authorisation in middle of JOB - etc
> From: Peter Nuttall > Date: Tue, 20 Apr 2010 07:48:46 +0200 > > Yes to all of that Puzzled me too ... Never seen it before I am > aware of the concatenation restriction on APF authorised load libraries > (and the integrity reasoning behind it), but there are no steplibs in the > job and the Joblib is, obviously, the same for all steps. > What is that "integrity reasoning"? Doesn't LINKLIST nowadays support a mixture of authorized and unauthorized libraries, with the authorization of the step depending on the status of the individual data set from which the module was loaded? Is it merely that since the programmer controls the content of STEPLIB there's little utility in supporting similar behavior in STEPLIB? -- gil -- 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: IEBCOPY losing APF authorisation in middle of JOB - etc
Yes to all of that Puzzled me too ... Never seen it before I am aware of the concatenation restriction on APF authorised load libraries (and the integrity reasoning behind it), but there are no steplibs in the job and the Joblib is, obviously, the same for all steps. I will chase it up with our sysprogs today, and see if they have found out anymore. PDSMAN does seem to be the main suspect here though. Cheers, Peter "Chris Craddock" Sent by: "IBM Mainframe Discussion List" 19/04/2010 05:54 PM Please respond to "IBM Mainframe Discussion List" To IBM-MAIN@bama.ua.edu cc Subject Re: IEBCOPY losing APF authorisation in middle of JOB - etc Ok, I am puzzled. Whether there is or is not an I/O appendage routine hidden away inside of dear old IEBCOPY seems immaterial. APF authorization is not something that just comes and goes within a step. Every new step can be authorized or not, but if the JOBLIB, STEPLIB or application specific library concatenations are the same for each step in the job, the system is going to get the same answer each time. There's just no such thing as "losing" APF authorization. For any new job step the system checks the AC attribute of the incoming job step program. If that's AC(1) then the system checks that the load library is APF authorized. If it IS then the job step is given control in an "APF Authorized" condition (i.e. JSCBAUTH=1) otherwise it is given control completely non-authorized. Now there are some gotchas of course. The one that trips up most young players is that for a load library to be considered APF authorized, EVERY dataset in the concatenation must be APF authorized. So even if you're fetching IEBCOPY from a righteously APF authorized library, if you have that library concatenated (e.g. in a JOBLIB or STEPLIB DD) with a non-authorized library then the entire concatenation is considered non-authorized and IEBCOPY won't run authorized. So assuming IEBCOPY is doing the right thing (FSVO "the right thing") on some steps and not others, I'd be looking for a difference in libraries between those steps. -- 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 This e-mail message, including any attachments transmitted with it, is CONFIDENTIAL and may contain legally privileged information. This message is intended solely for the use of the individual or entity to whom it is addressed. If you have received this message in error, please notify us immediately and delete it from your system. Please visit our website to read the full disclaimer: http://www.euroclear.com/site/public/disclaimer
Re: IEBCOPY losing APF authorisation in middle of JOB - etc
Ok, I am puzzled. Whether there is or is not an I/O appendage routine hidden away inside of dear old IEBCOPY seems immaterial. APF authorization is not something that just comes and goes within a step. Every new step can be authorized or not, but if the JOBLIB, STEPLIB or application specific library concatenations are the same for each step in the job, the system is going to get the same answer each time. There's just no such thing as "losing" APF authorization. For any new job step the system checks the AC attribute of the incoming job step program. If that's AC(1) then the system checks that the load library is APF authorized. If it IS then the job step is given control in an "APF Authorized" condition (i.e. JSCBAUTH=1) otherwise it is given control completely non-authorized. Now there are some gotchas of course. The one that trips up most young players is that for a load library to be considered APF authorized, EVERY dataset in the concatenation must be APF authorized. So even if you're fetching IEBCOPY from a righteously APF authorized library, if you have that library concatenated (e.g. in a JOBLIB or STEPLIB DD) with a non-authorized library then the entire concatenation is considered non-authorized and IEBCOPY won't run authorized. So assuming IEBCOPY is doing the right thing (FSVO "the right thing") on some steps and not others, I'd be looking for a difference in libraries between those steps. -- 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: IEBCOPY losing APF authorisation in middle of JOB - etc
On 18 April 2010 12:58, Rick Fochtman wrote: > > Not convinced this a true statment. Back in the late 1970s and early 1980s > with MVS, it was wired it into homegrown TSO commands and worked well. Then > with some new release it became authorized. I had Bill Godfrey (TSSO fame > and TSO GURU) under Contract working for the Air Force in the Pentagon and > he heard our moans. Bill headed off into the load module and determined IBM > was doing a GETMAIN for some very small number of bytes (4 I think) from a > Subpool which needed you to be authorized. No one ever determined why they > decided to do it. So the fix for our TSO commands was to go back into a SVS > system and get its IEBCOPY which did not need authorization and called it > XEBCOPY for use with the TSO commands. We ran that for years and may even > still be around. > --- > Wasn't there something about a new I/O appendage about that time? Something > that might have required authorization? IEBCOPY from the earliest MVS version had a PCI appendage and used EXCPVR, as far as I remember. You can see these routines IGG019C8 and IGG019FT in the MVS 3.8 source. The IEBCOPY main module IEBDSCPY does a GETMAIN for 48 bytes of subpool 253, but that code appears to have been added later. 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: IEBCOPY losing APF authorisation in middle of JOB - etc
Not convinced this a true statment. Back in the late 1970s and early 1980s with MVS, it was wired it into homegrown TSO commands and worked well. Then with some new release it became authorized. I had Bill Godfrey (TSSO fame and TSO GURU) under Contract working for the Air Force in the Pentagon and he heard our moans. Bill headed off into the load module and determined IBM was doing a GETMAIN for some very small number of bytes (4 I think) from a Subpool which needed you to be authorized. No one ever determined why they decided to do it. So the fix for our TSO commands was to go back into a SVS system and get its IEBCOPY which did not need authorization and called it XEBCOPY for use with the TSO commands. We ran that for years and may even still be around. --- Wasn't there something about a new I/O appendage about that time? Something that might have required authorization? Rick -- 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: IEBCOPY losing APF authorisation in middle of JOB - etc
>IEBCOPY does not need APF authorization for every >operation. Is step 8 doing something different from all >the other steps? Something that might need APF auth.? > Not convinced this a true statment. Back in the late 1970s and early 1980s with MVS, it was wired it into homegrown TSO commands and worked well. Then with some new release it became authorized. I had Bill Godfrey (TSSO fame and TSO GURU) under Contract working for the Air Force in the Pentagon and he heard our moans. Bill headed off into the load module and determined IBM was doing a GETMAIN for some very small number of bytes (4 I think) from a Subpool which needed you to be authorized. No one ever determined why they decided to do it. So the fix for our TSO commands was to go back into a SVS system and get its IEBCOPY which did not need authorization and called it XEBCOPY for use with the TSO commands. We ran that for years and may even still be around. jim -- 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
