On Tue, 2012-02-21 at 14:42 +0100, Jan Zelený wrote:
> 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
Pushed to master and sssd-1-8