Hi,
I think we're not handling the case where ldap_parse_result() fails
correctly and later we simply mark the request as done after checking for
more LDAP_CONTROL_PAGEDRESULTS. I'm not entirely sure that the attached
patch fixes the problem I was seeing, though. Let me explain:
I wasn't able to log in with cached credentials today. After some
investigation, I found that the cachedPassword attribute was missing
completely. Apparently the user entry was removed after a search returned
ENOENT and a new one without the cachedPassword attribute was saved
afterwards. I referenced the createTimestamp attribute of the sysdb entry
with logs and I saw this:
(Sat Feb 18 23:32:02 2012) [sssd[be[redhat.com]]] [sdap_get_generic_ext_done]
(0x0400): Search result: Server is unwilling to perform(53), Simple
Paged Results Search already in progress on this connection
(Sat Feb 18 23:32:02 2012) [sssd[be[redhat.com]]] [sdap_get_generic_ext_done]
(0x0040): Unexpected result from ldap: Server is unwilling to perform(53),
Simple Paged Results Search already in progress on this connection
(Sat Feb 18 23:32:02 2012) [sssd[be[redhat.com]]] [sdap_get_users_process]
(0x0400): Search for users, returned 0 results.
From the log it seems clear that the request was marked as done after
it found
no users, otherwise there would be another error message from
sdap_get_generic_done().
I'm not sure how the paging control is supposed to work and whether we
should also retry the next page if there is one even in the case when
ldap_parse_result() fails. Review comments are appreciated.