On Mon, 17 Nov 2014 19:55:10 -0500 Walt Farrell <[email protected]> wrote:
:>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? 1. Only those you create 2. Those that SAF says that you can :>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? If you create it, an optional ECB would be posted. Or an abend which the application would need to handle. :>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? A RESMGR routine. :>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. I agree that I do not see the business case. But the code is not that complex. -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
