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.

Reply via email to