Bug 143147

Summary: OpenLDAP should use cyrus-sasl-2
Product: Red Hat Enterprise Linux 3 Reporter: John Haxby <jch>
Component: openldapAssignee: Jan Safranek <jsafrane>
Status: CLOSED WONTFIX QA Contact: Jay Turner <jturner>
Severity: high Docs Contact:
Priority: medium    
Version: 3.0CC: shillman, srevivo
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-19 19:10:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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
Firefox/0.10.1

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
/usr/share/docs/cysis-2.*/README.RPM:

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

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
RHEL3.

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:
Always

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 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:
http://www.redhat.com/security/updates/errata/
 
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.