Bug 143147 - OpenLDAP should use cyrus-sasl-2
Summary: OpenLDAP should use cyrus-sasl-2
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: openldap   
(Show other bugs)
Version: 3.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jan Safranek
QA Contact: Jay Turner
Depends On:
TreeView+ depends on / blocked
Reported: 2004-12-16 21:08 UTC by John Haxby
Modified: 2015-01-08 00:09 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 19:10:54 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description John Haxby 2004-12-16 21:08:44 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020

Description of problem:
There have been several bug reports (eg bug 124806, bug 134979; I'm
sure there are more) relating to problems with SASL and LDAP.  I have
seen problems relating to sendmail and postfix not using SASL2.

The most recent problem I came across arose from this statement in

New development should be targetted to the 2.x library, using header
files in /usr/include/sasl, the libsasl2 library, and the /etc/sasldb2

Since I was integrating SASL authentication into our application, I
was pleased to see this as I didn't have to worry about the
compatability problems with cyrus-sasl-1.

The problem arises, however, as soon as any program that links
cyrus-sasl-2 attempts to use the OpenLDAP client libraries: these
critically depend upon cyrus-sasl-1 and as soon as you start using the
ldap libraries, your program will crash; usually when it calls
sasl_client_new() as the iplocalport parameter in the cyrus-sasl-2
comes from a zero value in the same position in cyrus-sasl-1.

I'm not alone in seeing this problem.  Sendmail has had to remain at
cyrus-sasl-1 (and has been the subject of bug reports as a result);
likewise Postfix which appears to have a forked version especially for

The problem has been fixed in RHEL4 beta but since RHEL3 is likely to
be in support for another three or four years we really do need
OpenLDAP to support cyrus-sasl-2 otherwise the suggestion that all new
development should use cyrus-sasl-2 is useless for anything that wants
to use LDAP (and anything that is providing an authentication service
is quite likely to want to do both -- see sendmail, postfix and the
scalix mail server for three such).   In our particular case, using
cyrus-sasl-1 is not possible as we critically depend upon features
that were introduced in cyrus-sasl-2.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Write a server program that uses cyrus-sasl-2 for authentication
and also uses the ldap client libraries for looking up, say, user data.
2.  Run the program.

Actual Results:  Watch the program crash horribly, usually in
sasl_client_new() called from the ldap library routines.

Expected Results:  The program shouldn't crash because it should only
use the one sasl library, the recommended one, the one for which there
are manual pages.

Additional info:

I know that there's a compat-openldap in RHEL4 that not only provides
the ldap-2.0 interface but also links against cyrus-sasl-2 which
nicely avoids all this mess.

There isn't a truly satisfactory way of working around this problem.

Comment 2 RHEL Product and Program Management 2007-10-19 19:10:54 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

Note You need to log in before you can comment on or make changes to this bug.