#1376 [RFE] Add support for suppressing group members
Closed: Fixed None Opened 7 years ago by sgallagh.

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

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

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.11 beta
priority: major => minor

Fields changed

proposed_priority: => Core

Fields changed

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

Fields changed

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: =>

Fields changed

cc: => henson

Fixed in 59f136c

owner: somebody => henson
patch: 0 => 1

Fields changed

resolution: => fixed
status: new => closed

For tickets already closed set the field to "Want"

selected: => Want

Fields changed

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

2 years ago

Login to comment on this ticket.

Metadata