> -----Original Message----- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > [email protected]] On Behalf Of Walt Farrell > Sent: Monday, November 17, 2014 7:55 PM > To: [email protected] > Subject: Re: Multiple address spaces (was: Redesigning ... ) > > On Mon, 17 Nov 2014 18:49:33 +0200, Binyamin Dissen > <[email protected]> wrote: > > >the enablement part of fork has elevated privileges to maintain integrity. > >There is no reason that a simple MVS service to allow connection to another > >address space could not be provided - if there was a need. > > > >All you need to do is mark the target address space non-swapable, add the > >STOKEN and set the SSAR bits. Then the ALET could be used for access. > > And how do you propose this "simple" service handle security/integrity and > determine which other address spaces your unauthorized program should be > able to connect to? > > How would the unauthorized program handle synchronization to ensure that > the other address space is really there, and that it is running the expected > program? > > Once the unauthorized program has (somehow) made the other address > space nonswappable, and then has managed to die without making the > target swappable again, how do you propose that the system take care of > that? > > There is no way that all of this can be a "simple" service. You've already got > fork(), so if you have a valid reason to run code in multiple address spaces > go > ahead and use it.
But then one is constrained to the semantics of fork() and the Unix multi-process philosophy. If a non-authorized program could create its own address spaces at the z/OS level, then the answers to your questions would be: 1. Only the AS's created by the originating program or created by those created AS's. 2. Synchronization to be sure the AS is there and running the program you expect is your responsibility, though this may require other, yet-to-be-invented methods (homework for the reader. . .); 3. If the original AS dies then all AS's it created die as a result, and all AS's created by the created AS's as well (akin to TCB termination); if one of those created AS's dies, it is your responsibility to detect it (via an AS termination exit akin to ESTAI but at the AS level, I would presume) and react accordingly. But all of that is a pipe dream, I know. We have what we have - authorization is required, and cannot be avoided - and that's the end of it. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
