(Cross-posting to RACF-L) Mark,
I have not worked with this APAR and PTF. Below is my interpretation of it. I agree this is a huge change. I think careful testing is needed to confirm this, and as I don't have access to a system with the change, I would be happy to help you with the test out of curiosity. This 'enhancement' appears to address an oft heard desire to be able to grant access to an alias, as these tend to be permanent, as an alternative to having to granting access to the underlying dataset, which tends to change, with the goal of simplify security administration. With this change, one will now be able to permit access to alias PRODUCT.LINKLIB instead of the related dataset PRODUCT.VERSION1.LINKLIB. Then, whenever a new version arrives, you simply point alias PRODUCT.LINKLIB at PRODUCT.VERSION2.LINKLIB and everyone will have access to the new version without you having to create a new profile for PRODUCT.VERSION2.LINKLIB. It might be possible to permit ordinary users access only to aliases and never permit them access to the underlying datasets. This might enable you to consolidate and streamline existing profiles. As for 'required action 1.' , I believe what they are alluding to is that if your aliases are currently named something like PRODVER.PRODUCT.LINKLIB and there are no RACF profiles for PRODVER, you will experience denial of access if RACF's SETROPTS PROTECTALL is in FAILURE mode (as is generally the case). If your aliases use existing High Level Qualifiers, and most likely they use the same HLQ as the related datasets, then you may not experience access problems because they'll already be covered by a profile. However, even if the latter is true, an existing alias might be covered by a profile like PRODUCT.** while the real dataset might be protected by profile PRODUCT.V*.**, and they could have very different access permissions. An exhaustive analysis of profiles and permissions is in order to ensure that the sudden switch in access authority checking from the dataset to the alias doesn't result in a loss of access. When first applying this PTF, I'd also be tempted to temporarily change PROTECTALL from FAILURE to WARNING just in case I'd missed something. If this works as per my interpretation, then I think the concerns raised by others are valid. If I can create an alias with a name to which I have access that points to a dataset to which I do not have access, I've now circumvented access controls for the latter. This is somewhat akin to having ALTER access to a catalog which lets you delete VSAM and SMS datasets without having ALTER to the dataset profiles. It appears, however, that IBM has addressed this concern. Googling APAR OA47269 (APAR OA49446 is essentially an addendum to this APAR) brings up links discussing new restrictions on DFSMSdfp DEFINE. To create an ALIAS, PATH, OR ALTERNATEINDEX, you will need ALTER access to the related dataset. This is going to make protecting sensitive datasets more complicated. I wonder if IBM's Health Check for APF library protection will now include aliases as well. Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel http://twitter.com/RSH_RACF www.rshconsulting.com ---------------------------------------------------------------------------- Upcoming RSH RACF Training - RACF Audit & Compliance Roadmap - DEC 5-9, 2016 - RACF Level I Administration - MAY 17-20, 2016 - RACF Level II Administration -MAY 3-5, 2016 - RACF Level III Admin, Audit, & Compliance - JUN 14-16, 2016 - Securing z/OS UNIX - WebEx - JUL 25-29, 2016 ---------------------------------------------------------------------------- -----Original Message----- Date: Thu, 28 Apr 2016 12:01:17 -0500 From: Mark Zelden <[email protected]> Subject: OA49446 on RSU1603 - RACF / DFSMS change I'm applying z/OS 2.1 RSU1603 and came across this PTF. Is anyone running with it in production and has it caused you any grief? This seems to change a behavior that has been around "forever", so it concerns me a bit even though there is a work around by defining a special RACF profile in the Facility class. ++ HOLD(UA80146) SYS FMID(HDZ2210) REASON(ACTION) DATE(15356) COMMENT (**************************************************************** * FUNCTION AFFECTED: DFSMS (OA49446) * **************************************************************** * DESCRIPTION : Update security definition * **************************************************************** * TIMING : Pre-APPLY * **************************************************************** This service requires certain actions to be performed before the PTF is applied. All the required actions appear in this PTF cover letter. RACF authorization checking is changed by this PTF for ALIASes, PATHs, and ALTERNATEINDEXes. Before, if the ALIAS was for a generation data set or a nonVSAM data set, the generation data set name or the nonVSAM name was used for the RACF authority check; for PATH and ALTERNATEINDEX, the associated CLUSTER name was used. Now, with this PTF, the RACF authority check is performed using the ALIAS, PATH, or ALTERNATEINDEX name. The required actions are: 1. Review the RACF profiles for names involving ALIASes, PATHs and ALTERNATEINDEXes. Depending on your naming conventions, no change may be necessary. The likely outcome if your ALIAS, PATH or ALTERNATEINDEX is not covered by an existing profile, will be a RACF failure due to insufficient authority. If this is the case, add or change RACF profiles for ALIASes, PATHs and ALTERNATEINDEXes to grant appropriate RACF authority. 2. If your installation cannot immediately tolerate the change in RACF authority checking, the old method of checking can be reinstated by defining a facility class profile with the name of STGADMIN.IGG.CATALOG.SECURITY.CHANGE and giving the user READ authority to that facility class.). Best regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:[email protected] Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
