Sean Burford wrote:
Hi,
We recently set about upgrading to Cyrus SASL 2.1.21 and OpenLDAP
2.3.24. We use NSS LDAP 207 to provide user and group information on
our LDAP servers. In our test environment OpenLDAP was segfaulting as
soon as any client attempted to speak SASL with it.
And you know what? Our 3 year old version 207 of NSS LDAP may be to
blame. From the NSS LDAP changelog version 210 fixed something (can't
find the 208 and 210 tarballs to confirm this):
210 Luke Howard
* initialize DBT structures
* fix SASL crasher
But you could argue that Cyrus SASL was also to blame.
The call to set mutex functions to be used by SASL must be done before
calling sasl_client_init/sasl_server_init.
The crash was caused by the NSS setting up SASL and then OpenLDAP
changing the SASL mutex functions and subsequently using SASL.
It sounds there is some strange interaction between NSS and OpenLDAP.
Can you tell me why NSS is trying to set up SASL?
The first use of SASL initialised gss_mutex to a dummy value of
(void *)1, and the later use attempted to lock that mutex using real
mutex code. It could be argued that Cyrus SASL should take care of
gss_mutex when sasl_set_mutex sets up proper mutex handlers, which is
what my patch does (to some degree). I won't try to defend my patch
as a proper fix.
