#1664 empty groups with filter_users_in_groups and enumerate enabled
Opened 6 years ago by bergolth. Modified 2 years ago

In my rfc2307 LDAP setup, group containing a system user appear empty if filter_users_in_groups and enumerate are enabled.

After disabling filter_users_in_groups or enumerate or removing the system user from the group, the other group members are shown again.

The attached log shows sssd startup, a "getent group withroot" at 08:58:28 and a "getent group withoutroot" at 08:58:40.


Fields changed

cc: => bergolth

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.9.4
priority: major => minor

Fields changed

milestone: SSSD 1.9.4 => SSSD 1.10 beta
rhbz: => todo

Fields changed

selected: => Not need

Moving tickets that are not a priority for SSSD 1.10 into the next release.

milestone: SSSD 1.10 beta => SSSD 1.11 beta

I've hit this too, and observed what happens to the ldb cache file by dumping it a couple of times and comparing.

What happens here is basically the following (assuming the clean run with empty cache):

  1. sssd (with ldap and enumerate enabled) backend starts
  2. Enumerate happens. Does no harm, puts user into cache.
  3. First getent issues an initgroups call which results in a ldap lookup. Adds list of groups user is a member of into cache and adds an initgrExpireTimestamp attribute indicating the group list is valid
  4. Another enumerate happens. This time it purges the cached group list, but leaves initgrExpireTimestamp in place
  5. Second getent causes another initgroups call. This time the cache hit occurs given initgrExpireTimestamp is valid, but the cached entry has been corrupted by preceeding enumeration, resulting in an empty result

Not sure what's the expected behavior thought.
Attaching a 3-way compare of my ldb dumps (shortened. beware it's a 200-column file)

_comment0: I've hit this too, and observed what happens to the ldb cache file by dumping it a couple of times and comparing.

What happens here is basically the following (assuming the clean run with empty cache):

sssd (with ldap and enumerate enabled) backend starts

Enumerate happens. Does no harm, puts user into cache.

First getent issues an initgroups call which results in a ldap lookup. Adds list of groups user is a member of into cache and adds an initgrExpireTimestamp attribute indicating the group list is valid

Another enumerate happens. This time it purges the cached group list, but leaves initgrExpireTimestamp in place

Second getent causes another initgroups call. This time the cache hit occurs given initgrExpireTimestamp is valid, but the cached entry has been corrupted by preceeding enumeration, resulting in an empty result

Not sure what's the expected behavior thought.
Attaching a 3-way compare of my ldb dumps (shortened. beware it's a 200-column file) => 1396033037743060
changelog: =>
review: => 0

Three way compare of cache file dump as the poisoning/corruption happens
enumerate.txt

Fields changed

cc: bergolth => bergolth, lkundrak@v3.sk

I'm not dismissing the bug report, but is there actually any reason to use enumeration at the moment? I would recommend to not use it, at least with large directories.

Replying to [comment:8 jhrozek]:

I'm not dismissing the bug report, but is there actually any reason to use enumeration at the moment? I would recommend to not use it, at least with large directories.

I don't really need it. A good enough workaround for me to address this issue is just disabling it.

Fields changed

mark: => 0

Fields changed

milestone: SSSD 1.13 beta => SSSD 1.13 backlog

Mass-moving tickets not planned for the next two releases.

Please reply with a comment if you disagree about the move..

milestone: SSSD 1.13 backlog => SSSD 1.15 beta

Metadata Update from @bergolth:
- Issue set to the milestone: SSSD Future releases (no date set yet)

2 years ago

Login to comment on this ticket.

Metadata