2009/5/11 Walt Farrell <[email protected]>: > On Sat, 9 May 2009 18:54:21 -0700, Ed Gould <[email protected]> wrote: > > >> Also if they do have access to amaspzap they can get around almost > anything, so I would still restrict that access (along with its alias's). > > That's not true, Ed. Access to AMASPZAP only allows you to read or write > data that you already have access to by other means, *except* for the one > case of zapping a VTOC. And for that, DASDVOL protection and/or operator > prompts supply the security. > > But for the other cases, if you have UPDATE to a data set then you can zap > it, but of course if you have UPDATE to the data set you can write to it > with anything else, too. > > That's why we're saying you need to protect the resources, not the utilities > that operate on them. Someone can always find another utility, or write > their own (and it doesn't take much programming experience to write a REXX > exec, shell script, PERL script, PYTHON script, etc. to do it).
Back in the 1980s, when our auditors wanted to restrict access to AMASPZAP, I explained to them that it is just an editor, like ISPF or TSO edit . Just as TSO EDIT is designed for editing datasets containing text, AMASPZAP is designed for editing datasets containing load modules. It doesn't let its user do anything they can't do using another tool; it is just sensible to use the most convenient and well optimized tool for the job. Amazingly, I did succeed in having their recommendation reversed. But today's auditors seem to be singing from the same 1970s songbook, and the same old ill informed recommendations come back again and again. Tony H. ---------------------------------------------------------------------- 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
