On Fri, 26 May 2017 09:02:14 -0500, John McKown <[email protected]> wrote:
>This question related back to the thread "ATTACH with RSAPF=YES" in which >the OP apparently wants a way to invoke a module from a non-APF authorized >library from a program which is running APF authorized. In today's >environment, the "simple" way (OPEN a DCB to a DDNAME which has the library >allocated to it, LINKX using DCB=) will result in an S306-C abend. > >So, first question is: Is this sort of things a reasonable desire? I don't >have a personal opinion. > >We did have this "need" in that we run an STC which requires APF >authorization. The vendor program needed a user-written subroutine in order >to "decode" some data fields into something it could recognize and process. >This subroutine was written by our programmer in COBOL. The last step of >implementation required that a sysprog copy the program object from the >production LIBRARY into the proper APF library. That's the proper general way, in my opinion. In the absence of additional hardware facilities, any other general mechanism will have to involve something like fork(), as we've discussed in that other thread. And, as you know, fork() has some significant considerations for such things as DD allocations, etc. > >Second question: IBM doesn't really like to be given a request with a >"implement this way" addendum. Which is reasonable. But I was trying to >think of a way to implement something like this myself using "magic". What >occurred to me is to look into using the MVS subspace facility. I don't >know much about it other than that CICS uses it to protect the CICS >"kernel" data areas from modification by user programs (running KEY=USER). >Seems like a decent idea to me. What say ye? The subspace facility doesn't do quite what you think it does. It does not protect the CICS areas from the user; that's done using system storage keys. The subspace facility allows you to segregrate a cooperating, non-malicious set of user code so that it can't modify the key 8 storage, or (I think) other transactions' key 9 storage, but the key descriptive words there are "cooperating" and "non-malicious". A program running in a subspace can freely switch out of subspace mode if it wants to, and then the subspace definition provides no protection. Thus, it is an advisory protection mechanism, that prevents well-intentioned programs from making a mistake. It is not a mandatory control, as provided by supervisor state, storage keys, or APF-authorization, and therefore cannot help if there is a possibility of having malicious code. It can not help in maintaining System Integrity. -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
