I have spent more time investigating the interaction of pam_ldap and
SASL, and have narrowed down the problem considerably, but still not
quite "got it".
The TLS options seem also to be the wrong direction; I can eliminate
TLS/SSL and the problem persists. By inserting lots of debug code, I
have found out where in pam_ldap the problem lives.
When SASL calls pam_authenticate, the pam_sm_authenticate subroutine in
pam_ldap.c gets run. This routine calls pam_get_user and pam_get_item to
obtain the username and password from imapd; do problem occurs here and
it gets the right username and password. It then calls a routine named
_do_authentication to check these against the ldap database.
Now when _do_authentication is run against a correct password, it
returns success and pam_ldap returns success, but imapd dies. If I
comment out the call to _do_authentication and just return success,
imapd does not die. So it would seem the problem lies with
_do_authentication.
But here is the wierd part -- as far as I can tell, _do_authentication
does not interact with imapd or the SASL library at all; it contains
only LDAP library calls to interact with the LDAP server! And remember,
this interaction doesn't generate any errors, but rather runs flawlessly
and returns success. It seems, though, that a side-effect of this
interaction is to screw up the imapd so badly that it dies with a
"signaled to death by 11".
??????? I do not understand! ?????
Can anyone explain to me how this might happen? Does OpenLDAP interact
with SASL somehow? I will also forward this to the pam_ldap list.