On Tue, 21 Jul 2009 07:14:13 -0400, David Cole wrote: > >The presumption seems to be that no "outsider" would have the ability >to put a program into APF authorized libraries. Well, what about 3rd >party vendors? We certainly provide the motivation to induce >"insiders" to place our programs into authorized libraries. But what >are we? "Insiders"? "Outsiders"? > >(As mentioned in my prior post, one technical way to partially >address this exposure would be for IBM to reduce the number of >reasons requiring a program to run authorized.) > What are the principal offenders? From an applications viewpoint, I see (the facilities provided by) IEBCOPY, IDCAMS, TRANSMIT/RECEIVE. (Others?) I find it bizarre that in a non-APF authorized state I can't manipulate data or rename data sets for which I have all otherwise necessary RACF authority.
What relief would be possible? o Could IEBCOPY be enhanced to operate without APF authorization? What performance degradation would this involve? o BPX1EXM appeared tantalizing when it first appeared. But it suffers the defect of not supporting useful DDNAME allocation. Would an APF-authorized wrapper invoked via BPX1EXM, allocating data sets specified by the TSOALLOC environment variable as used by the US^H^H OMVS command, then calling a target authorized utility be secure and useful? o The new-fangled (z/OS 1.4) Unix Rexx "address TSO" subcommand environment is a great help in some cases: it runs the TMP in a separate, presumably secure, address space. Alas, it's available only when Rexx is spawned from a shell. Would it be possible to access this environment with a suitable API call to the Rexx interpreter? -- 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
