Learn more about these different git repos.
Other Git URLs
In many cases, actually being able to list the members of a group is unnecessary. For the most part, access-control schemes will rely on whether a user's environment includes them as a member of a group (via initgroups() or getgroups()), and NOT by looking up the group to see if the username happens to be present.
This provides us with an opportunity to increase our performance on such systems. We should add a new per-domain option: {{{ignore_group_members}}}.
This would have the following effects: 1. When populating the results to send back to the client, we would suppress the membership list. In other words, the groups would appear to be empty. 1. When doing LDAP lookups for the groups (for any schema), we would filter out the 'member' and 'memberuid' attributes, so that our direct lookups would skip downloading large memberships or processing nested groups.
One side-effect to this would be significantly-increased performance when running {{{id <username>}}}.
The trickiest piece of this functionality would be ensuring that we don't delete existing member/memberOf linkages from the cache during group lookups that were put there by previous initgroups() requests. Thus, when this option is in play, member/memberOf should only be managed by initgroups() calls.
As one last data point, this is apparently the default behavior for winbind, which explains the visible performance disparity between these two projects when performing {{{id <username>}}}
For the record, my recommendation would be to leave this option disabled by default for the LDAP provider, but enabled by default for the in-progress AD-provider, since it's closer to what winbind does.
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.9 beta 4
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=832104
rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=832104 832104]
Putting back in NEEDS_TRIAGE. I don't think this is necessary for 1.9.0.
milestone: SSSD 1.9.0 beta 4 => NEEDS_TRIAGE
milestone: NEEDS_TRIAGE => SSSD 1.11 beta priority: major => minor
proposed_priority: => Core
summary: Add support for suppressing group members => [RFE] Add support for suppressing group members
Moving all the features planned for 1.10 release into 1.10 beta.
milestone: SSSD 1.11 beta => SSSD 1.10 beta
priority: minor => critical
To avoid any potential duplication of effort, I'm making a note here that I'm going to start working on this.
Not requesting the attribute from ldap is fairly easy, I already have a PoC that filters out the member attribute from the ldap query for groups, although I still need to add in the plumbing to make it optional. I'm going to need to study the code some more though to see what you mean about corrupting the cache between initgroups lookups and group lookups and making sure that doesn't happen.
design: => design_review: => 0 fedora_test_page: =>
cc: => henson
Fixed in 59f136c
owner: somebody => henson patch: 0 => 1
resolution: => fixed status: new => closed
For tickets already closed set the field to "Want"
selected: => Want
changelog: => In many cases, actually being able to list the members of a group is unnecessary. For the most part, access-control schemes will rely on whether a user's environment includes them as a member of a group (via initgroups() or getgroups()), and NOT by looking up the group to see if the username happens to be present. design: => N/A (trivial) review: => 0
Metadata Update from @sgallagh: - Issue assigned to henson - Issue set to the milestone: SSSD 1.10 beta
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/2418
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.