On Mon, Nov 17, 2014 at 9:05 AM, Tom Marchant < [email protected]> wrote:
> On Fri, 14 Nov 2014 18:31:23 -0500, Farley, Peter x23353 wrote: > > >I have often thought it was a mistaken design by IBM that prohibits > >non-authorized programmers from exploiting multiple address spaces > >and instruction-level space-switching facilities. > > How would you propose that such non-authorized programs access only > the other address spaces that they were permitted to access? In other > words, how would you protect the integrity of all address spaces if > unauthorized code were able to access other address spaces? > Hum, a good question. I might go with some sort of RACF authority. Perhaps a type of SURROGAT profile? Perhaps something like: SURROGAT execution-userid(of targe).XMUSER or SURROGAT target.jobname.XMJOB ? Or, as Peter indicated in a message subsequent to this one, perhaps only if the target ASID is a UNIX dubbed and in the same "process group" as the requesting process. In addition, I would also add "target does not have any APF authorized JSCBs other than the initiator ASCB. Target contains exactly one UNIX process (i.e. doesn't work with non-UNIX address spaces). Target address space is running with a single RACF ACEE (no use of TCB ACEE pointers).". There might be more that I am not thinking of. > > -- > Tom Marchant > -- The temperature of the aqueous content of an unremittingly ogled culinary vessel will not achieve 100 degrees on the Celsius scale. Maranatha! <>< John McKown
