First off, thanks to you, Lawrence, and the many others who helped
clarify why OpenLDAP 2.0.x + pam_ldap + cyrus-imaps-2.0.x won't play
together out-of-the-box. For those just tuning in to this thread, it's
because the SASL routines are (1) used both by cyrus-imapd and OpenLDAP
and (2) not re-entrant, so memory gets deallocated by one while the
other is still trying to use it. Poof -- core dump.
CMU people, please don't take the following personally; your work is
impressive and appreciated. But some things about it are less than
useful off the CMU campus, and I think SASL is one of them. My reasoning
is simple:
A non-re-entrant security layer is contradiction in terms. Security
layers are designed to be ubiquitous -- if SASL works out as planned,
every application involved in authentication will link to it. Problems
like these would be a dime a dozen (which is one reason SASL will not
become ubiquitous).
I think for most applications PAM is a much better alternative. It is
inherently simpler. It can support ticket systems by using Kerberos. It
can support access restrictions based on time-of-day, IP-address, and
such, which (correct me if I'm wrong) SASL cannot. If is far more widely
used and easily understood.
One PAM critic on this list said that PAM is easy to misconfigure, which
is true, but if we were all held back by stuff like that we'd be using
Macs. The philosophy of Unix is to give you enough rope to hang
yourself... and then a bit more for good measure.
Of course, one can always claim that SASL doesn't hurt anything, since
it can call PAM. But my experience has proven the falacy of the doctrine
of harmless layers. It turns out to be even more difficult than planned
for me to avoid the re-entrancy problem, because the LDAP encyption of
OpenLDAP 2.0.x gets broken when compiled --without-cyrus-sasl, and
OpenLDAP 1.x doesn't have any encryption, and I need my LDAP
communications encrypted (which is why the sasl-ldap patch also isn't an
option).
Which leads me to repeat my earilier question: how hard would it be to
replace SASL with PAM, thus producing, IMHO, a more useful imap server
for sites other than CMU. Basically this comes down to the question: how
many calls to SASL library APIs are there in cyrus-imapd? 10? 100? 1000?
If it's less than 100 I'd give it a try myself.
Thanks for listening,
David