Mark, There has been quite a bit if speculation about "why" IBM made this change. What was the integrity issue.
Like you, I was mildly curious. A lot of good people have made a lot of good points and now I have become very curious. As you and others have said, RACF DATASET protection can be used to prevent users from making updates. Assuming that all SMP/E, target, distribution and APF-authorized datasets are properly protected, there shouldn't be an issue. As many have said, RACF PADS can be used to limit those who may invoke SMP/E. I believe that there is a general consensus that it probably isn't solely related to the fact that GIMSMP runs AC(1). As we all know, if you cannot trust staff that has UPDATE access to an APF-authorized library, then all bets are off. I am unaware of any special access that GIMSMP would have when executed by a user who cannot normally update the datasets / HFS files affected by APPLY. At first I thought that a clever user could copy the SMP/E datasets and thereby get around the UPDATE protection (i.e. execute APPLY or ACCEPT using their copy of the SMP/E environment). But, so what? Who cares if they modify their own copies of the SMP/E environment? The target and distribution libraries will not be updated by any of the utilities that SMP/E invokes because SAF will prevent it. All of this lead me to believe that the issue may not be as critical as getting unauthorized access to a dataset or, worse, AC(1) capabilities. It is more likely a consideration that is specific to SMP/E commands. I therefore very much like your "stretch" hypothesis and would like to offer my own: Many of us are more cautious with ACCEPT than we are with APPLY. ACCEPT can delete things (e.g. SMPPTS members and TLIBs). More importantly, ACCEPT can modify an object in a distribution dataset that could conceivably be INCLUDEd into some other product that is installed into a different zone. Perhaps, in some large shop, an untested MOD was ACCEPTed into a DLIB and subsequently pulled into another product's LMOD (via an APPLY in some other zone), which then fell over. Just a thought, but I can "stretch" to envision some customers wanting to control those who may ACCEPT (i.e. limit it to a subset of those who may APPLY). Happy Easter all! Alan -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Mark Zelden Sent: Friday, April 02, 2010 06:46 To: [email protected] Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use On Fri, 2 Apr 2010 10:41:36 +0000, Bob Shannon <[email protected]> wrote: >We applied the APAR. We protect the SMP data. I'm sort of baffled why >IBM felt SAF support was necessary for SMPE. > >Since we are a development shop in which dozens of people use SMPE, we simply set the access to UACC(READ) which gives everyone access to all of the SMP/E commands. > It's not necessary, but I can "stretch" and see the case where a shop might want to let an ID or group have RECEIVE authority for example, but not let them to do an APPLY or not let them perform admin functions. Perhaps a production userid that does RECEIVE ORDER via a job scheduler on a nightly or weekly basis. For query only, the CSI can simply be protected from update via RACF data set profiles. I'd be mildly curious to know where the requirement came from. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:[email protected] Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
