Bug 166647

Are you using nscd?
Does
getent passwd tom
work (as opposed to
getent passwd | grep tom
)?

Uff! It depends on how the getent is called and if the nscd is running or not:

# service nscd start
Starting nscd:                  [  OK  ]
# getent passwd | grep tom
#
# getent passwd tom
tom:x:1014:513:System User:/home/tom:/bin/bash
#
# service nscd stop
Stopping nscd:                  [  OK  ]
# getent passwd | grep tom
#
# getent passwd tom
#


I did also discovered that this bug is only occurs if you are root or if program
runs with root priviledges. The common non-root user have no problem even the
nscd is running or not and even he runs 'getent passwd tom' or 'getent passwd |
grep tom'.

The openldap's slapd is used with default unmodified ACLs.

I did test to retrieve tom's LDIF with and without cn=Manager rights and did
look at diff and did not found anything strange:

$ ldapsearch -x uid=tom | sort > /tmp/nonmanager.txt
$ ldapsearch -x -W -D "cn=Manager,dc=company,dc=cz" uid=tom | sort >
/tmp/manager.txt
Enter LDAP Password: *********
$ diff -ruN /tmp/nonmanager.txt /tmp/manager.txt

(Result is attached as file diff.txt)

FIXME -- file diff.txt is empty of course. Time to one more cup of coffee tonight.

Can you then:
1) stop nscd
2) strace getent passwd tom as root
3) strace getent passwd tom as normal user
See where they differ?

Jakub, good point! I did found difference.

Non-root request is done as anonymous ldap bind, what is OK.

Root request is done as DN 'rootbinddn' defined in /etc/ldap.conf
with password taken from file /etc/ldap.secret. This request always fails
with ldap "invalidCredential" error.

glibc-2.3.5-0.fc3.1 sends password WITHOUT "\n" so it is OK while
glibc-2.3.5-10.3 sends password WITH "\n" so it FAILS.

Ldap server make difference between "password" and "password\n"

I dont know, what code exactly changed from FC3 to FC4 epoch.

This has nothing to do with glibc.   nss_ldap handles all the LDAP details.

That's a bug in nss_ldap 234 -- the newline isn't stripped off properly.  This
is fixed in Raw Hide, and will be fixed in nss_ldap-234-8.

I backported this fix from 235 to 234 and it is working very well.
Hope we will see this in 4/update/testing soon.

Created attachment 118140 [details]
Strip newline from password.

Strip newline from password patch from nss_ldap-235.

This bug is pretty fatal. It breaks down all samba PDC based networks.
Until the official fix will come (this century I hope) the fixed packages
are on http://crash.fce.vutbr.cz/crash-hat/4/nss_ldap/

What I see is that 'getent passwd | wc -l' always return 539 users, even if
there is more users in the LDAP DB.
I have created a special users for nss_ldap to connect to openldap, as described
in this howto:
http://samba.idealx.org/smbldap-howto.en.html#htoc31
What does this "magic" 539 number means?

(In reply to comment #0)
> # id tom
> uid=1014(tom) gid=513(Domain Users) groups=513(Domain Users)

If the command id works, then you need to add this option to
/etc/openldap/slapd.conf:
sizelimit unlimited

This solved my problem, now 'getent passwd | wc -l' returns all users
HTH

The sizelimit thing isn't related to the original filer's bug -- changing the
bug summary to reduce confusion.

This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.

Fixed in upstream.
Closing the bug.