[Date Prev][Date Next] [Chronological] [Thread] [Top]

crash: cyrus-imapd -> sasl -> pam -> pam_ldap -> libldap-2.x -> sasl



A problem has been detected when using both Cyrus 2.x and OpenLDAP 2.x
together if pwcheck_method is PAM and pam_ldap is used.

It does not fail for everyone.  For instance, on RedHat 7.0 using
system-auth as configured by authconf, pam_unix is used before
pam_ldap and the crash is not seen.

However, if pam_pwdb is used instead, crash happens.  It also happens
if pam_ldap is tried before pam_unix *unless* authentication fails:
that is, you try the wrong password and then you retry (in the same
connection, of course) the right one and does not crash.  Or does not
crash for a few of us.  The thing is fragile enough, so it may work by
dumb luck at any time.

The problem has been traced to the call to sasl_set_alloc in cyrus.c
in libldap, that is used to set the memory management routines used by
cyrus-sasl to those in liblber.  But in the scenario described in the
subject, the sasl library is what called libldap (indirectly through
PAM).  And now, libldap will call libsasl and change the memory
routines.

Apparently, the crash happens when pam returns to cyrus-sasl and it
tries to clean up, by calling the memfree routines in liblber and,
somehow (possibly pam unloads the libraries), they are not there
anymore.  The reason why pam_unix avoids the crash may be that it just
does getpwnam or getspnam that triggers loading libldap through
nss_ldap and the latter keeps libldap and liblber mapped until program
end.  That a failed authentication saves the day may be caused by a
similar hidden library load.

Removing the call to sasl_set_alloc avoids the crash.

Now, the questions are: Why do we call sasl_set_alloc?  Do we need it?
Always? On some platforms? Is it safe doing it when we were called by
libsasl itself? If not, how do we manage memory allocation when we are
running under libsasl?

Ideas?

Julio