On Tue, Mar 17, 2015 at 9:51 PM, Shmuel Metz (Seymour J.) <[email protected]> wrote: > In > <caajsdji6nc2qjhdq2gabj-u7s5jhsqr2jmdegmjlyrapcks...@mail.gmail.com>, > on 03/17/2015 > at 09:52 AM, John McKown <[email protected]> said: > >>Of course, I don't know of a _good_ method to ensure memory >>protection from a "rogue" program which runs in the same address >>space as a trusted program. > > Follow the rules for RSAPF=YES: > > Don't use user key storage > Don't share subpool zero > Don't let authorized and unauthorized subtasks run concurrently
Very good information. I'm just BOFH enough to allow a person to shoot themselves in the foot. Sometimes, I'll even supply the gun and ammo with the stock "but I don't suggest doing that" advice. I grant Charles the right to shoot himself in the foot. I am not a nanny. If he decides to do this, that is _his_ decision. I assume that he, and his management, will do a "risk assessment" and will accept the risk of doing this, or not. Personally, if this were my shop and someone wanted to do this in-house, they might be found at the bottom of the elevator shaft one day (not really, I'm not violent). If _I_ had to design something like this, I would most likely try the separate address space method using UNIX facilities. Or even encapsulating the APF code inside a dynamically created PC (Walt's suggestion?) and then just turning off APF entirely. This latter reeks of the "magic SVC" approach of the past, but it is not quite as dangerous. I might even consider trying to use SVC subsystem screening, depending. IMO, there is not a _safe_, _easy_, and _effective_ way to do what the OP wants. Especially not __easy__. > > -- > Shmuel (Seymour J.) Metz, SysProg and JOAT > ISO position; see <http://patriot.net/~shmuel/resume/brief.html> -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
