RACF, at least on z/OS, does not allow a GROUP to be a member of a group.. A RACF group can only contain RACF userids. Eg:
AG GROUP1 AG GROUP2 ADDUSER USER1 You can do a CONNECT of USER1 to GROUP1 and GROUP2. But you cannot do a CONNECT of GROUP2 to GROUP1. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM ________________________________ From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Billy Bingham Sent: Friday, August 06, 2010 9:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: (Fwd) Curiosity Question: System Security >From a colleague on the vse-l mailing list. Billy ------- Forwarded message follows ------- I only just this week discovered that the VSE BSM does not support group within group security. Meaning, if you have two security groups of users -- say, IT managers and IT employees -- and you try to include the IT managers as IT employees just by adding the IT managers security group into the IT employees security group, then the VSE BSM (as currently implemented) will not return the correct access levels for the IT managers so defined. IBM Level 2 confirmed that this is a restriction of the VSE BSM and, they think, also of RACF (but they weren't 100% certain). Can anybody familiar with RACF confirm or deny such a restriction? Can anybody familiar with other top-notch security products confirm or deny whether those products, also, sport such a restriction? It seems, to me, that group within group security would be such a commonplace thing to want to do that I'm surprised to find that the VSE BSM does not support this. Now, I do understand that such a defined sub-group would logically obtain the same access level as is defined for the main group. I further understand that in order to obtain a different access level for such a sub-group that the sub-group would have to be defined directly, as a main group, to the security resource in question. I also understand that, under the scenario I've described so far, this would result in the same group being defined twice to the same security resource -- once as a sub-group and once as a main group. However, I don't see this as a problem because a main group definition should logically take precedence anyway. I just object to having to always define only main groups in order to obtain the desired security access levels. Sincerely, Dave Clark WinWholesale Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 ********************************************************************************************* This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. ********************************************************************************************* ------- End of forwarded message -------
