Bug 566632 - nss_ldap bug causes nscd to crash with `ldap_result: Assertion `ld != ((void *)0)' failed.'
Summary: nss_ldap bug causes nscd to crash with `ldap_result: Assertion `ld != ((void ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nss_ldap
Version: 4.9
Hardware: All
OS: Linux
urgent
high
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact: Ondrej Moriš
URL:
Whiteboard:
Depends On: 488857
Blocks: 584502
TreeView+ depends on / blocked
 
Reported: 2010-02-19 01:27 UTC by Jatin Nansi
Modified: 2018-10-27 12:15 UTC (History)
12 users (show)

Fixed In Version: nss_ldap-253-9.el4
Doc Type: Bug Fix
Doc Text:
Previously, enabling the "nss_connect_policy oneshot" option in the /etc/ldap.conf configuration file may have caused an application crash. With this update, enabling "nss_connect_policy oneshot" works as expected.
Clone Of: 488857
Environment:
Last Closed: 2011-02-16 14:02:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0239 0 normal SHIPPED_LIVE nss_ldap bug fix update 2011-02-15 16:35:01 UTC

Comment 12 Ondrej Moriš 2010-07-08 13:01:06 UTC
Running "id omoris" on fixed nss_ldap with "nss_connect_policy oneshot" on i386 always returns 1 (failure) even though its output is correct:

# cat /etc/ldap.conf 
uri ldap://ldap.bos.redhat.com
base dc=redhat,dc=com
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
bind_policy soft
ssl start_tls
tls_cacertdir /etc/openldap/cacerts
referrals no
nss_connect_policy oneshot

# cat /etc/nsswitch.conf 
...
passwd:     files ldap
shadow:     files ldap
group:      files ldap
...

# id omoris ; echo $?
uid=14420(omoris) gid=14420(omoris) groups=14420(omoris),1070,1076
1

This happens on i386 only (I've tried two different i386 machines) and it does not matter if nscd is running or not. There is no relevant error message in /var/log/[messages | secure | audit/audit.log]. When "nss_connect_policy oneshot" is removed or "oneshot" is replaced by "persistent" it correctly returns 0.

Comment 13 Nalin Dahyabhai 2010-07-08 14:55:51 UTC
(In reply to comment #12)
> Running "id omoris" on fixed nss_ldap with "nss_connect_policy oneshot" on i386
> always returns 1 (failure) even though its output is correct:
> 
> # cat /etc/ldap.conf 
> uri ldap://ldap.bos.redhat.com
> base dc=redhat,dc=com
> nss_initgroups_ignoreusers
> root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
> bind_policy soft
> ssl start_tls
> tls_cacertdir /etc/openldap/cacerts
> referrals no
> nss_connect_policy oneshot
> 
> # cat /etc/nsswitch.conf 
> ...
> passwd:     files ldap
> shadow:     files ldap
> group:      files ldap
> ...
> 
> # id omoris ; echo $?
> uid=14420(omoris) gid=14420(omoris) groups=14420(omoris),1070,1076
> 1

That doesn't look correct -- the names for the supplemental groups with GID 1070 and 1076 weren't found, which is why id returned a non-zero exit status.  When I use the same configuration, on an x86_64 test system, it works as I'd expect.

Have you tried other architectures?  Is the CA certificate stored in /etc/openldap/cacerts and world-readable, with a symlink from /etc/openldap/cacerts/e569cb81.0 which points to it?

Comment 14 Nalin Dahyabhai 2010-07-08 20:25:41 UTC
Never mind, I can now confirm that the resolution failure you're seeing is also a bug.

Comment 19 Jaromir Hradilek 2010-07-16 14:24:59 UTC
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

New Contents:
Previously, enabling the "nss_connect_policy oneshot" option in the /etc/ldap.conf configuration file may have caused the "id <username>" command to exit with the following error message:

  ldap_result: Assertion `ld != ((void *)0)' failed.

With this update, enabling "nss_connect_policy oneshot" works as expected, and running the id command no longer fails.

Comment 24 Eva Kopalova 2011-02-09 13:12:18 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,5 +1,5 @@
 Previously, enabling the "nss_connect_policy oneshot" option in the /etc/ldap.conf configuration file may have caused the "id <username>" command to exit with the following error message:
 
-  ldap_result: Assertion `ld != ((void *)0)' failed.
+ldap_result: Assertion `ld != ((void *)0)' failed.
 
 With this update, enabling "nss_connect_policy oneshot" works as expected, and running the id command no longer fails.

Comment 27 Eva Kopalova 2011-02-14 15:57:53 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,5 +1 @@
-Previously, enabling the "nss_connect_policy oneshot" option in the /etc/ldap.conf configuration file may have caused the "id <username>" command to exit with the following error message:
+Previously, enabling the "nss_connect_policy oneshot" option in the /etc/ldap.conf configuration file may have caused an application crash. With this update, enabling "nss_connect_policy oneshot" works as expected.-
-ldap_result: Assertion `ld != ((void *)0)' failed.
-
-With this update, enabling "nss_connect_policy oneshot" works as expected, and running the id command no longer fails.

Comment 28 errata-xmlrpc 2011-02-16 14:02:00 UTC
An advisory 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 therefore 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.

http://rhn.redhat.com/errata/RHBA-2011-0239.html


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