Bug 37725 - rpm-4.0-4 -U|V|F core dumps if nss_ldap-149 in use
rpm-4.0-4 -U|V|F core dumps if nss_ldap-149 in use
Product: Red Hat Linux
Classification: Retired
Component: openldap (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-04-26 00:53 EDT by David Young
Modified: 2014-08-31 19:24 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-15 14:44:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Young 2001-04-26 00:53:10 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.7 (Macintosh; U; PPC)

rpm core dumps if I try to -i (install), -U (update) or -F (freshen) on any 
rpm... -q (query) or -e (erase) works fine. Using strace, I was able to 
determine that seg fault was happening right after /etc/nsswitch.conf was 
read. Editing /etc/nsswitch.conf to remove my "ldap" directives solved 

Reproducible: Always
Steps to Reproduce:
Fresh RH7 instal
OpenLDAP rpm package removed
OpenLDAP 2.07 installed from source
nss_ldap rpm package removed
nss_ldap-149 installed from source
pam_ldap-105 installed from source
Edit /etc/nsswitch.conf and add "ldap" to the "passwd:" line
Run rpm and attempt to -U -F or -i some package.

Actual Results:  seg fault - core dump

Expected Results:  update, install or freshen of package

A few lines of output from strace that led me to find the solution:

# strace rpm -Uvh ed-0.2-19.i386.rpm

  read(13, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1787
  read(13, "", 4096)                      = 0
  close(13)                               = 0
  munmap(0x4025d000, 4096)
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
Comment 1 Jeff Johnson 2001-04-26 08:50:50 EDT
This is an rpm problem only because rpm is statically linked. The real problem
has to do with glibc provided name services on top of ldap/pam modules.

Off to ldap for analysis, jakub added to CC list for ideas, bounce it back to
me if you think that rpm should do a
call as early on its execution path as possible to insure that name services
are functional.
Comment 2 Jay Fenlason 2005-09-15 14:44:57 EDT
Try Fedora Core 4. 

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