attachment
sssd-filter.log

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

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

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

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.