OK - I was regretting my post somewhat, but perhaps this will reduce the pain:
APF authorized programs can be called from JCL, from a TSO TMP and from Unix System Services. For TSO and -perhaps?- USS (note context) the specific programs that can be called is restricted. The programs that can be called (APF authorized) from JCL is not restricted. Why not have a parmlib member to restrict the use of PARMX to specific programs? This could apply to SUB=MSTR and SUB=JESx equally. I considered a RACF profile, but this is not to restrict user access, merely to insure PARMX is only used with programs that can handle it (correctly). I realize there is still an issue re: existing control blocks, but at least the system integrity issue could be addressed. It might even be possible to allow PARMX for all unauthorized programs, while restricting it's use with authorized programs. Does that help? On Wed, 23 Sep 2009 19:32:54 -0500, Paul Gilmartin <[email protected]> wrote: >On Wed, 23 Sep 2009 10:09:50 +0200, Gilbert Saint-Flour wrote: > >>Jim Mulder wrote: >> >>> .... Karl Schmitz decided to look at some of IBM's APF authorized >>> programs in SYS1.LINKLIB to see if he could find one which assumed >>> that the parm length did not exceed 100. My recollection is that >>> the first one he looked at (selected from a component in which >>> he had prior expertise, not alphabetically) could behave incorrectly >>> if the parm length was larger than 100. >> >And Jim didn't say whether "behave incorrectly" meant merely >that it reported an invalid PARM and exited with RC=8, or >whether it behaved more pathologically, such as overrunning >a buffer. I fear it would have been the latter. > >Are APF authorized programs particularly sensitive to this >paradoxically because they, as a defensive measure, are apt to >copy the PARM into protected storage to prevent the caller's >modifying it dynamically? > >>I wrote a test job (nothing to do with APF-authorised programs) which executes >>the COBOL compiler (IGYCRCTL), a COBOL program, the high-level assembler >>(ASMA90), an assembler program, and the LOADER, which all successfully >>process a long PARM (200 bytes) - it's all here: >> http://gsf-soft.com/Freeware/EXECPGMJ.shtml >> >>Again, none of the programs are APF-authorised. To pass a long PARM to the >>programs, this test job uses the EXECPGM command which is available here: >>http://gsf-soft.com/Freeware/ >> >I looked this over. It's a TSO Command Processor (I think), >which means it's not directly useful from JCL. Nor are >JCL symbols readily accessible from TSO (though system >symbols may be with a little effort). Yah, I know, someone >has a hack that extracts JCL symbols by scanning the text >of the JCL. Yuk. > >And Rick Fochtman kindly sent me the source of his utility. >Like Gilbert's it's useful for its purpose, but suffers >limits. It tailors a DD CONTROL file, replacing every >occurrence of &0, &1, ..., &9 with positional tokens from >PARM, writing the result to SYSIN, then invoking a program >named in the first token in PARM. I could imagine this >feeding into a file-to-PARM utility (many are available) >to create a long PARM. Alas, I think of Eileen's CICS >problem, where the combined length of the needed path >names is likely to exceed 100 characters. > >-- gil > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] 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 [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
