Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionBrian J. Atkisson
2017-05-17 19:31:45 UTC
Description of problem:
We have a request coming from the business to support groups with membership and other attributes hidden from all but select users. These would be groupofgroup groups (not posixgroups). I'm fairly sure we can accomplish this with DS ACIs today, but it was not clear how to do with IdM's RBAC model
Consider the group:
dn: cn=it-iam-team,cn=groups,cn=accounts,dc=ipa,dc=dev,dc=example,dc=com
objectClass: ipaobject
objectClass: top
objectClass: ipausergroup
objectClass: groupofnames
objectClass: nestedgroup
cn: it-iam-team
description: IT IAM Team Group
member: uid=user1,cn=users,cn=accounts,dc=ipa,dc=dev,dc=example,dc=com
Under this RFE, there are a couple of use-cases
1. All users and anon. binds would be able to see the cn=it-iam-team,cn=groups,cn=accounts,dc=ipa,dc=dev,dc=example,dc=com group and description, but not view the group membership.
2. Group is completely hidden from all but chosen users
Individual users and/or groups should define access to both these use-cases. That is, I should be able to define a group (or use the hidden group itself) to grant access to view group membership.
Comment 2Alexander Bokovoy
2017-05-22 13:45:28 UTC
Can we get more explanation of a use case:
- Who are the users that would be allowed to see the membership information?
- Are these users machine accounts, for example?
Comment 3Patrick Crownover
2017-05-25 16:01:58 UTC
Ideally: Any members/admins of the group + any one (user or service account) added to a specific ACL associated with the hidden group, can view the group or membership. This service account would not necessarily be a member of the group.
Brian,
would you be able to provide an actual example of a group that is going to be hidden? What I need to understand is what the group is going to be used for.
The problem of concealing memberships is that the group is also reported as the memberof attribute in member's entries. And this mechanism is used for various things.
I need to figure out if you are asking to conceal individual memberof attributes from members as well, and need to figure out if this is possible (or needs code), what is the impact on performance and what is the impact on functionality (this may depend on what the group is used for).
Thank you.
Comment 5Patrick Crownover
2017-06-13 15:18:36 UTC
I have included 2 examples below. If you don't think they explain things well I can re-word/re-write them but I tried to give examples of the differences and how the system could be used even if they are not likely examples.
Example 1: Group is public but membership is private.
John wants to create a group to discuss how much he loves GMail but since it is currently a social stigma, no one would join if others could see they were in it. John makes a group with the name and all of the information but marks that membership is private and therefore, only visible to admins and to current members of the group. Bill is looking through the groups and sees that there is a group about loving GMail and can see things like when it was created, what type of group it is, who the owner/admin is but not who is a member. He asks John if he can join and John adds him to the group. Now if Bill looks at IdM, he can see the full list of membership within the group as he is now a member.
Example 2: Group is completely private
Karen wants to create a group about firing one of her employees, Tim, but needs to create a group of users with associated email list to discuss it. She doesn't want Tim to know until it has been discussed and finalized so she creates a Private group. If someone were to see this group in IdM, they would see the smallest footprint possible, including hiding the group name if possible, and no membership. Allie is also going to be added to the group to discuss Tims dismissal but when she looks for the group she cannot find anything because it is private. Karen goes through and adds Allie as well as the other associated managers/people of interest to the group. When Allie looks in IdM again, she can now see all the details about the group as well as its membership which lets her know who she is discussing this with. In the end, they decide to give Tim more time and delete the group. Tim is never the wiser about all of this because he could never see the group or any information around it.
Thank you taking your time and submitting this request for Red Hat Enterprise Linux. The request was cloned to the upstream tracker a long time ago (see link to the upstream ticket above), but it was unfortunately not given priority either in the upstream project, nor in Red Hat Enterprise Linux.
Given that this request is not planned for a close release, it is highly unlikely it will be fixed in this major version of Red Hat Enterprise Linux. We are therefore closing the request as WONTFIX.
To request that Red Hat reconsiders the decision, please reopen the Bugzilla with the help of Red Hat Customer Service and provide additional business and/or technical details about it's importance to you. Please note that you can still track this request or even offer help in the referred upstream Pagure ticket to expedite the solution.