AW: Calling authorised modules from non-authorised environments ( cross post from IBM-Main)
Many thanks to all of you for the suggestions. I shall have to assess the various aspects and decide on how to continue. The only solution that is not acceptable is the "open" method. Jon -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Im Auftrag von Tom Anderson Gesendet: Mittwoch, 15. Juni 2005 17:57 An: IBM-MAIN@BAMA.UA.EDU Betreff: Re: Calling authorised modules from non-authorised environments ( cross post from IBM-Main) Given all that has been said here, I would suggest that you approach it this way - 1. Determine what is your allowable/acceptable margin for error (i.e. Walt's points about possible program control, etc, etc). 2. How "intrusive" can the service be? Is it acceptable to "open" the dataset to check, etc. (By the way, Wayne pointed out that open was the "easiest" way to do what you want, not necessarily the least intrusive). 3. If you have decided to go/stick with doing "proxy checks" (for want of a better term), then build and test the core module that performs these checks and make sure it delivers the results you are seeking. The point here is to, for the time being at least, forget about the coms mechanism, until you have something that provides the required service. 4. Once you have a service that works, then decide on the communications mechanism. If you aren't comfortable with a user SVC or PC routine, perhaps some form of networking (sockets?) mechanism better suites your needs and comfort level. > > > > > Now my routine needs to be called from programs not running under > > TSO. The problem is that IKJEFTSR only runs within a TSO > > environment. <> Suggestions from the IBM Main list were to create a > > SVC or PC or use BPX1FRK/BPX1EXM. > > Those are your only legal choices. It is no accident that is is hard > to get control in an authorized condition. Maintaining integrity is > more important than making the facilities easy to use. Unfortunately, > the APF authorized AC(1) job step program is a blunt instrument and > all of the officially blessed mechanisms for call-level authorization > are complex to set up and designed to be relatively long lived, > amortizing their set up costs over many interactions. > > There is as yet no formal mechanism for transient requirements like > yours. One proposal evaluated by z/OS Design is to use the security > manager to augment authorization checks. In efffect, to provide > security mediated control over certain functions that currently > require APF or higher authorization. I don't know if that plan went > anywhere, but one of the designers will probably tell us. > > In any case since that option doesn't exist yet it won't do you any > good right now. Beyond that you should consider the objections raised > by Ed Jaffe and Walt Farrell. It is surprisingly difficult to know > specifically what SAF question to ask in order to get the right answer > in the context of your caller. If you are trying to decide whether or > not to allow access to a dataset, you may as well avoid the trouble > and just use recovery to cover up the S913 abend. > > CC > > -- > 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 -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.3/15 - Release Date: 14.06.2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.3/15 - Release Date: 14.06.2005 -- 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
Re: AW: Calling authorised modules from non-authorised environments
>That's why John suggested a BPX1FRK to create a disposable child >process that will be the one that "no longer exists". The program >invoked by BPX1EXM will return status to the forking parent that >continues to operate. Why not use spawn()? >(But I don't so much wish to administer z/OS on it.) Hey, you're missing a great experience ;-) Peter Hunkeler Senior IT Specialist, IBM zSeries Technical Sales Support, Switzerland -- 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
Re: AW: Calling authorised modules from non-authorised environments
In a recent note, Jon Renton said: > Date: Tue, 14 Jun 2005 23:02:18 +0200 > > this sounds quite unconventional and uses unix services/functions. If I Unix Services have been part of z/OS as long as z/OS has existed. Prior to that, Unix Services were part of OS/390 from its very beginning. And before that they were present (under a different name) in the predecessor of OS/390. How many decades does it take for a service to become "conventional"? I'd say that Unix Services is at least more conventional than installing a rogue SVC or PC to gain authorization. > understand correctly the calling task no longer exists after > processing. As a result my calling routine will not receive the > result and can not continue processing as required. > That's why John suggested a BPX1FRK to create a disposable child process that will be the one that "no longer exists". The program invoked by BPX1EXM will return status to the forking parent that continues to operate. > -Ursprüngliche Nachricht- > Von: IBM Mainframe Discussion List [mailto:[log in to unmask]] Im Auftrag > von McKown, John > Gesendet: Dienstag, 14. Juni 2005 22:30 > > >From my reading of BPX1EXM, it replaces the currently executing > >process image. This means that he must first do a BPX1FRK to > >"fork()". [ ... ] > Also note that the "parent" process must then use the BPX1WAT or > BPX1WTE function to wait for the "child" to terminate and then > retrieve the integer "return code" from the "child" process. > Very similar to ATTACH, isn't it? > The "child" can only pass back 4 bytes of information (like a > "return code"). > True, but incomplete. My understanding is that descriptors in the parent process _are_ inherited by the child, and an unlimited amount of information can be passed in either direction via pipes connected to those descriptors. > === > Man, for the old days of the "secret SVC" which flipped the APF > bit in the JSCB "on" and "off". > I, too, wish I had my very own big computer. (But I don't so much wish to administer z/OS on it.) -- gil -- StorageTek INFORMATION made POWERFUL -- 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
AW: Calling authorised modules from non-authorised environments
John, basically the calling programs process various generic dataset templates. Dataset lists are built and the contents need to be checked against RACF using certain given userids. The subroutine is called per dataset with the required user. Upon return the rc, status and access (read, update, alter, control, none) are returned. It is not a high volume situation. Where can I find the assembler list? Thanks Jon -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Im Auftrag von john gilmore Gesendet: Dienstag, 14. Juni 2005 23:07 An: IBM-MAIN@BAMA.UA.EDU Betreff: Re: Calling authorised modules from non-authorised environments I can think offhand of 20 odd ways to do what you want to do. To decide among them we need to know more about the volume of data that are input to and output from your routine, the frequency with which it is called, its complexity, and its size. I also suggest that this thread be moved to the assembler list, where its subject belongs and others who have the necessary competences can contribute. John Gilmore Ashland, MA 01721 U.S.A. _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- 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 -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.6.6 - Release Date: 08.06.2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.6.6 - Release Date: 08.06.2005 -- 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
AW: Calling authorised modules from non-authorised environments
John, this sounds quite unconventional and uses unix services/functions. If I understand correctly the calling task no longer exists after processing. As a result my calling routine will not receive the result and can not continue processing as required. Jon -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Im Auftrag von McKown, John Gesendet: Dienstag, 14. Juni 2005 22:30 An: IBM-MAIN@BAMA.UA.EDU Betreff: Re: Calling authorised modules from non-authorised environments > -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin > Sent: Tuesday, June 14, 2005 3:03 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Calling authorised modules from non-authorised > environments > > > In a recent note, Jon Renton said: > > > Date: Tue, 14 Jun 2005 21:02:38 +0200 > > > > for a method to get/keep/set/obtain the required > authorisation so that my > > SAF checks works. > > > Another thought: have you investigated BPX1EXM? It has its own > limitations, but it's less roundabout than my earlier suggestion. > > -- gil > -- > StorageTek > INFORMATION made POWERFUL >From my reading of BPX1EXM, it replaces the currently executing process image. This means that he must first do a BPX1FRK to "fork()". His "calling" code must then determine if it is the "parent" or "child". The "child" must then do the BPX1EXM to call the APF authorized function. Remember that all parameters being sent to the program invoked by BPX1EXM must be included in the parameter list. You __cannot__ pass an address to something in the "parent" (it is now in a separate address space!), nor can you pass an address to something in the "child" because the process is __replaced__. That means that all program-resident areas are gone. As are all GETMAIN'ed areas. The only really useful information that you can pass would be similar to what you pass via a JCL PARM= parameter. Because the service must create a new process image for the specified program to run within, the prior process image is completely cleaned up. In MVS terms, the system ends a step within a job and then inserts a new step for the specified program to run in. Any MVS task-related resources that existed in the old job step are cleaned up. The new job step that is created has no allocations associated with it, with the exception of the MVS data sets that may be built into the STEPLIB environment for the new process image. When the newly created job step ends, the flow of the job continues, as it normally does, to the next sequential step in the job, depending on the completion code of the ending step. Also note that the "parent" process must then use the BPX1WAT or BPX1WTE function to wait for the "child" to terminate and then retrieve the integer "return code" from the "child" process. The "child" can only pass back 4 bytes of information (like a "return code"). === Man, for the old days of the "secret SVC" which flipped the APF bit in the JSCB "on" and "off". -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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 -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.6.6 - Release Date: 08.06.2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.6.6 - Release Date: 08.06.2005 -- 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
AW: Calling authorised modules from non-authorised environments
Gil, I don't think that this will work as the TSO evironment is not available when running normal MVS workload (i.e. not using IKJEFTxx) Jon -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Im Auftrag von Paul Gilmartin Gesendet: Dienstag, 14. Juni 2005 21:44 An: IBM-MAIN@BAMA.UA.EDU Betreff: Re: Calling authorised modules from non-authorised environments In a recent note, Jon Renton said: > Date: Tue, 14 Jun 2005 21:02:38 +0200 > > Now my routine needs to be called from programs not running under TSO. > The problem is that IKJEFTSR only runs within a TSO environment. I am > looking for a method to get/keep/set/obtain the required authorisation > so that my SAF checks works. > > Can anyone help? > Roundabout. Use BPXWUNIX to run a Rexx EXEC to use "address TSO" to provide a TSO environment. Theoretically it should work; practically, the overhead is likely to be brutal. -- gil -- StorageTek INFORMATION made POWERFUL -- 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 -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.6.6 - Release Date: 08.06.2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.6.6 - Release Date: 08.06.2005 -- 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
