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.
Ack,
I think that simply returning an error is a good approach. Most of these
errors are unlikely to be recovered from by an attempt to retrieve the next
page. If there are some exceptions, we can explicitly state them in the
condition.
Thanks
Jan