Fields changed

blockedby: =>
blocking: =>
coverity: =>
feature_milestone: =>
milestone: NEEDS_TRIAGE => SSSD 1.9.2
testsupdated: => 0

Fields changed

owner: somebody => pbrezina
status: new => assigned

reproducer
main.c

As Daniel found out, the problem here is this line in nss_cmd_retpwent():

n = pdom->res->count - cctx->pwent_cur;

It somehow happens that pwent_cur > res->count, which puts -1 in n when there is no other domain to try. This brings sssd_nss into infinite loop.

We have discussed this with Jakub a lot. We came up with only one possible scenario when this could happen:

1. setpwent() is called, sssd will fetch all users and store them in memory for enum_cache_timeout seconds
2. client calls getpwent() several times
3. client is idle long enough, that users stored in the memory are expired and deleted from the memory
4. several users are deleted from LDAP
5. client calls getpwent() again
6. sssd fetches all users again but the result does not contain deleted users
7. if enough users where deleted, res->count < pwent_cur

I have managed to reproduce it, but there are so many coincidences that must happen together, that I don't really believe this is the reason why it is happening:

1. the client must be idle between two getent() calls for at least enum_cache_timeout seconds (default is 2 mins)
2. enumeration must occur in this time span (default period is 5 mins)
3. this enumeration must also remove deleted users from cache (default is 12 hours)
4. at least res->count - pwent_cur - 1 user must be deleted from LDAP

_comment0: As Daniel found out, the problem here is this line in nss_cmd_retpwent():

{{{
n = pdom->res->count - cctx->pwent_cur;
}}}

It somehow happens that ''pwent_cur > res->count'', which puts ''-1'' in ''n'' when there is no other domain to try. This brings sssd_nss into infinite loop.

We have discussed this with Jakub a lot. We came up with only one possible scenario when this could happen:

1. ''setpwent()'' is called, sssd will fetch all users and store them in memory for enum_cache_timeout seconds
2. client calls ''getpwent()'' several times
3. client is idle long enough, that users stored in the memory are expired and deleted from the memory
4. several users are deleted from LDAP
5. client calls ''getpwent()'' again
6. sssd fetches all users again but the result does not contain deleted users
7. if enough users where deleted, res->count < pwent_cur

I have managed to reproduce it, but there are so many coincidences that must happen together, that I don't really believe this is the reason why it is happening. => 1349783261802014

I would propose the following:

1. Put additional check into the loop so that we simply abort and error out on the special condition. It's not technically the best solution but it's way better that eating up 100% of CPU in a tight loop.
2. file a new ticket to track the root cause.
3. create an instrumented build for the reporter. We are quite lucky the person is technical and willing to test, so he might be able to run a build with extra debugging to give us more information.

Fields changed

patch: 0 => 1

master: 89b93a4

resolution: => fixed
status: assigned => closed

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

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.