Maybe some others are willing to comment... I thought that there was a short-cut to take for auth checking these days.. if you didn't really need to keep the ACEE around and you just want to do a quick check to see if someone is auth'd for something. Perhaps it was a dream or a wish. Anyone?
Rob Schramm On Thu, Apr 21, 2011 at 4:40 PM, McKown, John <[email protected] > wrote: > > -----Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:[email protected]] On Behalf Of Patrick Roehl > > Sent: Thursday, April 21, 2011 2:57 PM > > To: [email protected] > > Subject: Mixing Auth and Non-Auth Modules > > > > I have a situation where APF-authorization is needed by a new > > subprogram > > that performs RACF functions. This was working fine until it > > came time to call > > the new subprogram from the main program, which does not need to be > > authorized. Making the whole process authorized seems silly > > (or worse), in > > addition to being inconvenient as there are many STEPLIB > > entries involved. > > > > I tried running the main program from an authorized LNKLST > > library, but quickly > > ran into S306-12 when trying to load a program from the STEPLIB. > > > > Is the best option to handle this setting up a separate > > region to handle the > > authorized calls and communicating via a PC? It looks like a > > PC client would > > have to be authorized, which defeats the purpose. > > > > How has this been solved in the past? > > > > Thanks for any suggestions and/or examples. > > APF is generally an "all or nothing" affair. z/OS, and MVS before it, was > not designed to swap between APF and non-APF authorized states. You can do > the APF to non-APF switch relatively easily. But it is generally a one way > street. TSO does it by having two TCB trees. TSO starts up APF authorized, > but resets the APF when the TMP does an ATTACH. But before that it creates > an APF authorized subtree. When you run an APF authorized TSO program, it is > run on the APF subtree and not the normal subtree. The normal subtree is > "frozen" via the STATUS STOP operation during APF authorized function to > decrease the likelihood of "cracking" the APF code. CICS switched back and > forth using its SVC somehow (I don't know the internals). > > Now, being the weirdo that I am, I'd likely do my APF authorized work by > using the UNIX fork() and exec(), where I exec() a module which is in the > UNIX filesystem marked as APF authorized. Depending on what I need to do, I > would either use shared memory (shmat) or set up a UNIX bidirectional > unnamed PIPE if the APF task worked more like a "server" and would be > invoked multiple times. It's just seems easier to me. Or use UNIX message > queues for communications. I have a better understanding of using pipes. > > The plus of the UNIX solution is that the invoker does not need to be APF > authorized at all. It just needs to be able to do the UNIX fork() and exec() > of the APF authorized "service" program. I'd likely secure the service > program by having the appropriate UNIX security on the executable file in > the UNIX filesystem (using ACLs if necessary). An alternative / enhancement > would be to have the UNIX program do a RACF security call of some sort to > see if the invoker is authorized. This latter would be better if the routine > is multifunction where the sub functions need to be individually authorized, > perhaps with differing access lists. Like what ISMF does. > > -- > John McKown > Systems Engineer IV > IT > > Administrative Services Group > > HealthMarkets(r) > > 9151 Boulevard 26 * N. Richland Hills * TX 76010 > (817) 255-3225 phone * > [email protected] * www.HealthMarkets.com > > Confidentiality Notice: This e-mail message may contain confidential or > proprietary information. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original > message. HealthMarkets(r) is the brand name for products underwritten and > issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake > Life Insurance Company(r), Mid-West National Life Insurance Company of > TennesseeSM and The MEGA Life and Health Insurance Company.SM > > > > ---------------------------------------------------------------------- > 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 > -- Rob Schramm Senior Systems Engineer w: 513.305.6224 ---------------------------------------------------------------------- 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
