David Wright wrote:
>
> I am faced with the same "signaled to death by 11" problem on RH 7.1
> that has been reported in this list several times before. I think I
> understand the problem, but I need a little coaching to implement a
> solution.
>
> Here's the problem: whenever I login correctly,
> # telnet localhost imap
> Trying 127.0.0.1...
> Connected to localhost.localdomain.
> Escape character is '^]'.
> * OK sartre.rprc.washington.edu Cyrus IMAP4 v2.0.16 server ready
> . login <username> <password>
> Connection closed by foreign host.
> the connection closes, and the spawned imapd process
> imapd[16162]: login: localhost.localdomain[127.0.0.1] <username>
> plaintext
> imapd[16192]: pam_ldap: ldap_set_option(LDAP_OPT_X_TLS_REQUIRE_CERT):
> Unknown error
> imapd[16192]: pam_ldap: _set_ssl_options failed
> master[16154]: process 16192 exited, signaled to death by 11
> dies ignominiously.
>
> I am using
> sasl_pwcheck_method: PAM
> and pam_ldap to authenticate against an OpenLDAP database. Note that
> pam_ldap complains that it has been passed an option
> LDAP_OPT_X_TLS_REQUIRE_CERT
> with which it is unfamiliar
>
> My guess is that the LDAP_OPT_X_TLS_REQUIRE_CERT option is the problem.
> Needless to say, that means the the previously touted explanations
> regarding Berkley DB linking problems are red herrings.
Looks like you're probably correct.
> So... how can I get cyrus-imap not to require TLS for a plaintext login?
> I realize the cyrus team thinks they are doing me a favour by requiring
> this, but there really needs to be a simple way to disable it in
> configuration files. Also, imapd certainly shouldn't be comiting suicide
> just because a PAM module doesn't understand its request for some
> exceedingly obscure LDAP_OPT_X option.
What makes you think that cyrus-imap is requiring TLS? SASL simply asks
the pam module to verify a username/password pair, how the pam module
does this is completely opaque to SASL and imapd. How you looked at the
source code of pam_ldap? I took a quick look, and even though I know
next to nothing about LDAP, its pretty obvious that pam_ldap is trying
to use STARTTLS when talking to the LDAP server. Furthermore, it is
trying to require a client certificate.
I can't explain why pam_ldap works with other services and fails when
used with imapd/SASL, mainly because I don't care to dig into the
pam_ldap and SASL code any further, but I'd either trying disabling
SSL/TLS in pam_ldap by using the --disable-ssl option to configure or
try setting the tls_checkpeer option in pam.conf to off.
I'm guessing that one of these two things should change the behavior
that you are seeing. I can't guarantee that this will fix the problem
entirely, but it *should* get you going in the right direction.
> If I use another PAM module instead of pam_ldap, for example the trivial
> pam_permit, which always returns success, it all works. I (and, of
> course, everyone else in the world) can login successfully, and nobody
> dies! However, lest you think that a hopelessly buggy pam_ldap is the
> problem, you should know that the selfsame pam_ldap is working fine with
> about 42 other services I offer (login, netatalk, passwd, samba, ssh,
> ...) including an old cyrus-imapd-1.6.24 installation on another machine.
Have you seen any complaints of other pam modules not working with the
current versions of imapd/SASL? I haven't, so I would keep looking at
pam_ldap until you get some better evidence that SASL is doing something
incorrect.
My $.02
Ken
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
