Bug#462958: bug in pam/pam_ldap

[fireshark3 at gmx.net]

Hi,

since the last update, sasl seems to invert the realm and service parameters and my clients aren't able to authenticate to the mail-server anymore. I have more or less the same configuration of that described above.

I tested sasl with following command:

	testsaslauthd -f /var/spool/postfix/var/run/saslauthd/mux -u webmaster at intranetcenter.de -p test -s imap

And I got following output from sasl:

	saslauthd[6677] :cache_get_rlock : attempting a read lock on slot: 64           
	saslauthd[6677] :cache_lookup    : [login=webmaster at intranetcenter.de] [service=] [realm=imap]: not found, update 	pending                                       
	saslauthd[6677] :cache_un_lock   : attempting to release lock on slot: 64       
	saslauthd[6676] :handle_sigchld  : child exited: 6677  

After three of these tests I get "size read failed 0:" on the client console and a "Segmentation fault" from saslauthd.

The realm service parameter is empty and the realm contains the service name: [realm=imap]. If I use services other that imap and pop, everything is fine.
Prior to the update, everything went fine. Unfortunately, I do not have the update mail anymore and I could not determine what files were been updated but I'm pretty sure there is a problem with the pam_ldap package. The files " /etc/pam.d/imap" and " /etc/pam.d/pop" contain:

	auth            sufficient      pam_ldap.so
	account         required        pam_ldap.so


> I got everything working for me again temporarily by telling saslauthd to use ldap directly instead of via pam.

Can you tell me how you did that? Thx!

Best regards.


-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer