Bug 166647 - nss_ldap 232-234 mistakenly treats the end-of-line character as part of a password
nss_ldap 232-234 mistakenly treats the end-of-line character as part of a pas...
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: nss_ldap (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-24 07:41 EDT by Petr Krištof
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-22 07:05:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Strip newline from password. (368 bytes, patch)
2005-08-26 06:59 EDT, Petr Krištof
no flags Details | Diff

  None (edit)
Description Petr Krištof 2005-08-24 07:41:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc3 Firefox/1.0.6

Description of problem:
Command 'getent' doesnt returns items stored in ldap.

I had a working FC3 server where all users was stored on ldap.
Commands 'id' and 'getent' always showed needed info about these
users.
After upgrade to FC4, the getent never returns passwd or group
info about these users, so many program (vsftpd and more) doesnt
work. As result, the system is unusable.


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

How reproducible:
Always

Steps to Reproduce:
1. Store users account in ldap
2. Run 'getent passwd'

  

Actual Results:  Command doesnt return none info about ldap users.

# getent passwd | grep tom
# 

Expected Results:  # getent passwd | grep tom
tom:x:1014:513::/home/tom:/bin/bash
#

Additional info:

# id tom
uid=1014(tom) gid=513(Domain Users) groups=513(Domain Users)
#

# grep ldap /etc/nsswitch.conf
passwd:     files ldap
shadow:     files ldap
group:      files ldap
Comment 1 Jakub Jelinek 2005-08-24 12:52:38 EDT
Are you using nscd?
Does
getent passwd tom
work (as opposed to
getent passwd | grep tom
)?
Comment 2 Petr Krištof 2005-08-24 16:50:48 EDT
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)
Comment 3 Petr Krištof 2005-08-24 16:58:51 EDT
FIXME -- file diff.txt is empty of course. Time to one more cup of coffee tonight.
Comment 4 Jakub Jelinek 2005-08-25 11:55:08 EDT
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?
Comment 5 Petr Krištof 2005-08-25 13:09:43 EDT
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.

Comment 6 Ulrich Drepper 2005-08-25 13:17:35 EDT
This has nothing to do with glibc.   nss_ldap handles all the LDAP details.
Comment 7 Nalin Dahyabhai 2005-08-25 13:52:03 EDT
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.
Comment 9 Petr Krištof 2005-08-25 16:46:22 EDT
I backported this fix from 235 to 234 and it is working very well.
Hope we will see this in 4/update/testing soon.
Comment 10 Petr Krištof 2005-08-26 06:59:21 EDT
Created attachment 118140 [details]
Strip newline from password.

Strip newline from password patch from nss_ldap-235.
Comment 11 Petr Krištof 2005-08-26 07:05:20 EDT
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/

Comment 12 Oliver Schulze L. 2005-09-22 04:19:25 EDT
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?
Comment 13 Oliver Schulze L. 2005-09-23 17:24:09 EDT
(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
Comment 14 Nalin Dahyabhai 2005-09-27 19:02:40 EDT
The sizelimit thing isn't related to the original filer's bug -- changing the
bug summary to reduce confusion.
Comment 15 Christian Iseli 2007-01-22 06:48:07 EST
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.
Comment 16 Petr Krištof 2007-01-22 07:05:45 EST
Fixed in upstream.
Closing the bug.

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