Bug 112266 - getgrent calls go into a loop
Summary: getgrent calls go into a loop
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: nss_ldap   
(Show other bugs)
Version: 2.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Jay Turner
Depends On:
Blocks: 116726
TreeView+ depends on / blocked
Reported: 2003-12-16 20:15 UTC by Brian Baggett
Modified: 2015-01-08 00:07 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-04-22 00:52:15 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Code from Kurtis D. Rader @ IBM that exposes flaw in nss_ldap-189 (615 bytes, text/plain)
2003-12-16 20:18 UTC, Brian Baggett
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:109 normal SHIPPED_LIVE Updated nss_ldap package fixes password handling, possible infinite loop 2004-04-21 04:00:00 UTC

Description Brian Baggett 2003-12-16 20:15:41 UTC
Description of problem:
Recently we discovered when installing IBM's Websphere MQ
(http://www-306.ibm.com/software/integration/wmq/) on our servers that
utilize LDAP that if the nsswitch.conf had files in front of LDAP,
that MQ would not function properly, so we had to put LDAP first. 
This isn't the right way to do it and we wondered why this was the
only application to require this.

We told IBM that MQ was broken, they said nss_ldap was broken.  They
gave us code to prove it was broken.  In a file attached called ibm.c
you can see that if, using the nss_ldap-189 RPM on RHEL AS/ES/WS 2.1,
getgrent calls will go into an infinite loop if 'group: files ldap' is
in /etc/nsswitch.conf instead of 'group: ldap files'.  Compiling and
running the code will confirm this problem.  IBM's internal tracking #
for this issue is PMRs 92341,122 (I think).

This behavior does not occur in version 207 of nss_ldap that ships
with RHEL 3.

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

How reproducible:

Steps to Reproduce:
1. Compile the attached code (gcc -o ibm ibm)
2. Run the resulting executable.
3. Watch as the results loop through the # of iterations defined on
about line 19 (ie if( ++n == 10000 ) break;)
Actual results:
The getgrent call will loop continuously.

Expected results:
The getgrent call should list all the GID's in the LDAP directory once
and then stop.

Additional info:

I decided to be proactive and search for a solution myself before
posting this bug.  I took the 207 source that ships with RHEL 3's
nss_ldap SRPM and its patches and the spec file from the 189 SRPM that
ships with RHEL 2.1 and merged it so that version 207 is built from
the spec file for 189.  The resultant SRPM is attached.  When tested
against the ibm.c code I referenced, the getgrent call functions as
expected when nsswitch.conf has 'group: files ldap'.

Since I know it is RH policy not to up versions of libraries included
with distributions, but rather to backport fixes I will attempt to
identify the exact fix and backport that to 189 in the hopes that RH
will put out another nss_ldap-189 RPM that fixes this (big) problem.

Comment 1 Brian Baggett 2003-12-16 20:18:44 UTC
Created attachment 96568 [details]
Code from Kurtis D. Rader @ IBM that exposes flaw in nss_ldap-189

Comment 2 Brian Baggett 2003-12-16 20:24:29 UTC
The SRPM mentioned in the bug report can be found here:

Comment 3 Brian Baggett 2003-12-16 21:51:18 UTC
I've confirmed that versions 189-203 have this problem.  Version 204
is the first version in which this behavior was fixed.  Identifying
which code fixed it (if I can).

Comment 9 Brian Baggett 2004-04-12 18:35:39 UTC
Update from the good folks at RedHat:

"This apparently happens with RHEL 2.1's glibc if an enumeration
function doesn't set *errnop to ENOENT when it returns
NSS_STATUS_NOTFOUND. We are not sure that the version of nss_ldap is a
factor, as we can reproduce this problem with version 217 but not on
later releases. We are still in process of a patch to correct this issue."

Comment 10 John Flanagan 2004-04-22 00:52:16 UTC
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.


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