> In my view, simply, no facility should *ever* elevate the authority of its > caller.
An admirable desire, however as pointed out earlier, there are circumstances where even standard IBM software has had to go down this route - eg TSO and AUTHTSF/PGM/CMD. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: 05 March 2014 16:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Storage Protection On Wed, 5 Mar 2014 15:32:03 +0000, Rob Scott wrote: >Please use google and search the IBM-Main archives for JSCBAUTH for *many* >discussions about why you should not be flipping it on and off. > >Apart from the fact that it is difficult to secure any facility that elevates >the authority of the caller, there is also the multi-tasking aspect to >consider. > In my view, simply, no facility should *ever* elevate the authority of its caller. Discussions such as this reinforce my belief in the utter folly of allowing privileged and unprivileged code to operate in the same address space. It's complex; Byzantine, and disproportionately difficult to secure. I think z/OS UNIX got it right. (AFAIK.) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
