On Sun, 24 Dec 2017 12:17:22 -0700, Paul Gilmartin <[email protected]> wrote:
>On 2017-12-24, at 11:01:38, Farley, Peter x23353 wrote: >> >> If truly a DOS attempt, then this would be followed the next day by >> promotion to the street for the responsible programmer and reprimands for >> the code reviewer(s) for missing such a trick. >> >But the DoS could be inadvertent, by a novice programmer, unprivileged, >outside the production stream, not subject to review. > >And for this, DYNALLOC provides somewhat better protection than JCL >because such a person would probably lack S99WTDSN authority. > >It's a pity that RACF allows ENQ on a DSN with no authority to >access that data set. But that would require that JCL distinguish >between intent to write and not to write, and more. I have to be pedantic here and point out RACF does not allow or prevent access to anything, gil, except its own resources. RACF for the most part merely answers security questions asked by others, and they are the ones that allow or deny access. Therefore, RACF is not allowing an ENQ on a DSN, because RACF has no idea that an ENQ is being done. If anyone were to control that, it would be data set allocation, who would have to invoke RACF to ask if the user would have authority to eventually OPEN the data set. (And, by the way, it's a difficult question for RACF to answer or more properly for allocation to ask, for several reasons. Among them, the possibility of discrete profiles means that until the data set is allocated so the DSCB can be read, allocation doesn't have all the necessary information to pass to RACF.) -- Walt
