Walt Farrell wrote: >>Binyamin Dissen wrote:
>>:>Users who are granted access to these resources have the potential to undermine system security regardless of any data set protections you may have in place. >>Now that IS scary. It seems to imply that SMP bypasses data set security. >No, it does not imply that. You may, of course, infer that, but you'd be >wrong :) It is the CALLER of RACF, for example in this case, SMP/E, which may or may not bypass data set security! Think, for example, DFDSS which bypass normal checks if you have access to ADMINISTRATOR keyword on some of its commands via some STGADMIN profiles in class FACILITY. Only the CALLER which calls RACF may 'bypass' RACF or data set security. It is up to them to follow RACF answer or not and then honouring RACF answer. The software calls RACF (if designed to do this) and then decides to honors RACF results (of course, if designed to do so) and then follow it own designed way. Nothing scary, only common practise. ;-D RACF itself cannot stop or allow accesses. It is the caller to allow/deny access. Actually in this case, SMP/E does not have any access beside normal accesses to datasets. So any software decides (if designed) to do a RACROUTE call. Then that software decide to honor any contents in Register 15 passed back by this call. It seemed to me that SMP/E designers added some more RACF calls in their new version of SMP/E. That is what this APAR is about. >And we will not describe any details of the actual exposure. Of course. (and no one can argue (or has any courage) with Walt Farrell! ;-D ) Groete / Greetings Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
