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

Re: OpenLDAP 2.0.x + pam_ldap + cyrus-imapd-2.0.x



David Wright wrote:

> I and quite a few other users of the cyrus-imapd system have found a
> problem which occurs exclusively when we authenticate using the PAM
> module pam_ldap linked against the OpenLDAP 2.0.x libraries. I am
> writing to ask whether this bug and any potential solutions are known to
> the wider OpenLDAP and pam_ldap communities.
>
> The basic problem is that, with the authentication scheme mentioned,
> imapd segfaults when pam_ldap returns success. Like anyone presented
> with this problem, I initially presumed the problem lay with cyrus-imapd
> (or with the cyrus-sasl library it uses). More careful investigation
> tends to case suspicion elsewhere:
>
> 1) The problem does not occur with any other PAM module, or with a patch
> which allows SASL to authenticate via LDAP directly. That would tend to
> cast suspicion on pam_ldap, but...
>
> 2) pam_ldap works fine with dozens of other applications. That would
> tend to cast suspicion on cyrus-imapd or the cyrus-sasl library. Hmm, we
> seem to be going in circles here.
>
> 3) By commenting out sections of pam_ldap, printing debug messages, etc,
> I found that the problem occurs only when the _do_authenticate
> subroutine in pam_ldap.c is executed. There is no PAM code in that
> subroutine, only calls to OpenLDAP routines! This is very wierd: the PAM
> exchange between  cyrus-imapd and pam_ldap runs without a hitch; the
> LDAP exchange between pam_ldap and my OpenLDAP server also runs without
> a hitch. Yet the latter (not the former!) exchange seems to have the
> side-effect of killing the cyrus-imapd server.
>
> 4) The above behaviour occurs even when the OpenLDAP server is on a
> different machine, so it can't be the server that is causing the
> side-effect. The side effect must be the fault of the client LDAP
> libraries. Or of cyrus-imapd/sasl for being susceptible to the side-effect.
>
> 5) This conclusion is strengthened by the observation (due to Phillip
> Sacha) that when pam_ldap is linked against OpenLDAP 1.x or
> Netscape-LDAP libraries, the problem goes away... even when
> authenticating against an OpenLDAP 2.0.x server. This would seem to lay
> guilt on OpenLDAP libraries rather then cyrus-imapd/sasl.
>
> Finally, two more incidental observations:
>
> a) Entering a wrong password does not kill imapd. Furthermore, if I
> first enter a wrong password, then a right password, I can log in
> without killing imapd. pam_ldap seems to cache some info during a
> session, and it's not having to look up that info a second time prevents
> the side-effect. This may provide a clue as to which OpenLDAP APIs are
> at fault.
>
> b) Several people (eg Norbert Sendetzky) have reported that the
> precompiled pam_ldap binary distributed by RedHat does work. Use of ldd
> reveals that it is linked against the OpenLDAP 1.2.x client libraries.
>
> Can any usrers and/or devs provide more detailed observations which
> would allow us to identify the guily party and file a clear bug?

You might try to join the process with gdb __before__ it sigsegs
but after it has forked, and send a backtrace to OpenLDAP's ITS
system.

I remember hearing something like that, but I can't remember when
or where, sorry.

Pierangelo.


--
Dr. Pierangelo Masarati               | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale                | fax:   +39 02 2399 8334
Politecnico di Milano                 | mailto:masarati@aero.polimi.it
via La Masa 34, 20156 Milano, Italy   | http://www.aero.polimi.it/~masarati