Over the years, in multiple shops, I have come across multiple sysprogs that have created new APF libraries. As you say, it is needed to perform their job. However, ensuring that those libraries were appropriately protected may not have been their job (perhaps it should have been, but that is a different issue). After many months or years, it was discovered that those APF libraries did not have appropriate protection. One can argue that company had poor procedures, or not enough staff, etc. which should be addressed, or you could provide a facility to mitigate the situation.
The mere fact that a library is APF authorized implies that you probably only what highly trusted people updating it. If you could put your highly trusted people on the access list of just one profile that protected all APF libraries that would help reduce the human error factor or the don't care factor. It does mean higher overhead, but protecting APF libraries is important. Of course, if you have good procedures that are always followed, you don't need this kind of feature. Human error (and it's not my job) is really hard to eliminate. The new hire who does not know or understand your naming standard can introduce a hole. CSVAPF protects who can change the APF list. That is different from protecting the content of the APF libraries. What I had suggested was method to allow you to protect (with a single profile) all currently APF authorized libraries from unauthorized update or access regardless of its name, volume, etc. In other words, even if you had DATASET ALTER authority to a APF library, you could not update it unless you also had UPDATE to the special APF profile. Of course, this added protection does not apply while the libraries are not in the APF list or from another system with a different APF list. Obviously my suggestion was not bullet proof and had a few holes. I think the RACF administrator can and should ask about new APF libraries. Not whether the library is needed, but whether it is appropriately protected. Don Williams -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of R.S. Sent: Wednesday, April 07, 2010 2:42 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use Don Williams pisze: [...] > A fair number of years ago I submitted a DCR suggesting that customers > should have an optional facility to control access to APF libraries. I don't > remember the details I suggested. Well, what control did you suggest, at least in general? I ask, because there are CSVAPF.nnnn profiles (CSV*.** in general) in the FACILITY class. For 10+ years. Of course we still have regular DATASET control along with AUDIT(ALL) - to trace activities of persons who have authorization. > Perhaps it was CLASS(FACILITY) > 'APF.data-set-name' or maybe a new class CLASS(APFLIB) 'data-set-name'. Looks quite similar to CSVAPF.libname CL(FACILITY). > In > either case, the profile would apply to all APF libraries, in addition to > their normal RACF profiles. APF libraries would have some protection, even > if they had no regular data set profile. > A profile like CLASS(APFLIB) ** > UACC(READ) would prevent updates to all APF libraries, but allow execution. DATASET profiles already provide such control. UPDATE allows changes, while read allows read and execution. Why do you think that something else is needed? Just curious. BTW: (this only my observation, YMMV) I noticed that CSV*.** profiles are rarely used (never used in fact). Maybe the reason is that APF/LNKLST/LPA changes are done by sysprogs, and in fact RACF admin has no reason to ask "why" when a sysprog wants to change any of the lists. The answer would be "because it's my job, I'm installing ABC product". -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 0000025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
