On Tue, 15 Dec 2009 11:21:07 -0500, Thompson, Steve wrote: > >Let me point out two possible security risks. > >Assume that the real file name is 44 characters long and that is the way >it is held in the VTOC. > >Now, let's assume that you do not have permission to that file. BUT, you >know that if you build a "long name" that uses your userid as the HLQ >and prepend that to the DSN, you will cause SAF to be passed the LONG >name, not the real name, and this will allow you, via volume specific >allocation, to now read that data (or write to the file). > Wouldn't that risk exist with the current IDCAMS ALIAS facility? Isn't SAF checking done on the actual (VTOC) data set name, not on the alias?
>Now, let us say that you want to cause a problem for the system. So you >pick a data set that is 44 characters long. You prepend your userid, and >under TSO you do an allocate with OLD. ENQUEUE SYSDSN will be for the 44 >characters. You see where this is going? > That problem exists now; additional use of aliases would only aggravate it. By experiment, if my job contains a DD statement for an alias, a SYSDSN ENQ is issued for the alias at job initiation. At step initiation, a catalog lookup is performed and an ENQ is attempted for the RELATED name, without WAIT. Failure of that ENQ is lethal (JCL ERROR? I forget exactly.) -- gil ---------------------------------------------------------------------- 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
