#2341 sssd-ldap handles redundant group members incorrectly
Closed: Fixed None Opened 6 years ago by adbisaro.


I'm using sssd(8) to look up group memberships from an LDAP server, using the "rfc2307bis" schema. I observe that my friendly neighborhood LDAP server does recursion of nested groups to provide a flat list of "member" attributes, but does not discard redundant members. That is, consider LDAP groups test_group_A and test_group_B with members and subgroups like this:

    dn: cn=test_group_A,ou=User Groups,ou=Groups,dc=example,dc=com
    member: uid=alice,ou=People,dc=example,dc=com
    member: uid=bob,ou=People,dc=example,dc=com
    groupMember: cn=test_group_B,ou=User Groups,ou=Groups,dc=example,dc=com

    dn: cn=test_group_B,ou=User Groups,ou=Groups,dc=example,dc=com
    member: uid=bob,ou=People,dc=example,dc=com
    member: uid=carla,ou=People,dc=example,dc=com

If I query my LDAP server with ldapsearch(8) for test_group_A, I see repeated member entries. Viz.:

    myhost$ ldapsearch -LLL -x -H ldap://ldap.example.com cn=test_group_A member
    dn: cn=test_group_A,ou=User Groups,ou=Groups,dc=example,dc=com
    member: uid=alice,ou=People,dc=example,dc=com
    member: uid=bob,ou=People,dc=example,dc=com
    member: uid=bob,ou=People,dc=example,dc=com
    member: uid=carla,ou=People,dc=example,dc=com

Observed Behavior

If I look up group membership for test_group_A through sssd(8), I get an incomplete member list:

    myhost$  getent group test_group_A

Enabling verbose debugging shows that sssd is unhappy about redundant members, with the log file showing complaints of "User was looked up twice, this shouldn't have happened". Nonetheless the group lookup succeeds yielding partial data. All members after the first repeated entry are discarded.

Expected Behavior

Either return the full list of members, silently discarding (only) duplicate "member" attributes without error, or reject the group in its entirety such that "getent group" prints nothing and exits with return value 2. (The former is preferrable, but the latter at least avoids labeling partial data as success.)

Fields changed

rhbz: => 0

Pavel, can you please assess whether this is something we can fix easily? If so, let's fix it in SSSD.

If not, then I would defer this ticket to a later release, because this scenario is quite rare and we have bigger fix to fry in 1.11.x/1.12

owner: somebody => pbrezina

Fields changed

patch: 0 => 1

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.12.0


if you are comfortable patching your code, would you mind helping us test the patch? You can download it from https://patchwork.acksyn.org/patch/6268/ for instace.

resolution: => fixed
status: new => closed

Metadata Update from @adbisaro:
- Issue assigned to pbrezina
- Issue set to the milestone: SSSD 1.12.0

3 years ago

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/3383

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.