misc/161456: on a system bound to an LDAP server, top tries to get the whole LDAP content to resolve uids

Patrick Proniewski patpro at patpro.net
Mon Oct 10 09:30:11 UTC 2011


>Number:         161456
>Category:       misc
>Synopsis:       on a system bound to an LDAP server, top tries to get the whole LDAP content to resolve uids
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Oct 10 09:30:10 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:     Patrick Proniewski
>Release:        7.3-RELEASE-p7 and 8.2-RELEASE-p3
>Organization:
Université Lyon2
>Environment:
FreeBSD foo.univ-lyon2.fr 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:45:57 UTC 2011     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

and 

FreeBSD bar.univ-lyon2.fr 7.3-RELEASE-p7 FreeBSD 7.3-RELEASE-p7 #0: Tue Sep 27 13:10:21 UTC 2011     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

>Description:
According to its man page, top(1) will read the whole passwd database at launch time, to resolve numerical uids into user logins.
When the system is hooked to an LDAP server for user authentication, top(1) will try to download the whole content of the LDAP database.

If the LDAP shutdowns the connection (because of you reach a limit for example), top(1) dies and display nothing but the error message "Broken pipe". That's how it works when I bind the FreeBSD system to our Sun Directory Server: top(1) downloads about 3MB of LDAP data, the LDAP server kills the connection, top(1) dies.

If the LDAP sends immediately and error but doesn't kill the connection, top(1) will resolve each foreign uids thru the LDAP, one at a time, and will properly display its output. that's how it works when I bind the FreeBSD system to our LDAP proxy: top(1) tries to download LDAP content, the proxy replies "The server is not configured to pass through control 1.2.840.113556.1.4.319", top(1) send individual request to resolve discrete uids, top(1) displays its output.

My FreeBSD systems use nscd, but I made a full cache flush before each test. Note: even without flushing, the first behavior is always true.

>How-To-Repeat:
0 - PREREQUISITES: bind your FreeBSD system to an LDAP server
- install nss_ldap and pam_ldap
- edit /etc/pam.d/sshd to add this line:

#auth		sufficient	pam_krb5.so		no_warn try_first_pass
#auth		sufficient	pam_ssh.so		no_warn try_first_pass
+ auth            sufficient      /usr/local/lib/pam_ldap.so      no_warn ignore_authinfo_unavail
auth            required        pam_unix.so             no_warn try_first_pass

and this line:

account		required	pam_login_access.so
+account		required	/usr/local/lib/pam_ldap.so	no_warn ignore_authinfo_unavail ignore_unknown_user
account		required	pam_unix.so

- edit /usr/local/etc/nss_ldap.conf and /usr/local/etc/ldap.conf to add proper LDAP binding (provide binddn and bindpw)
- edit /etc/nsswitch.conf to add "ldap" and/or "cache" on those lines (cache is for nscd):

group: cache files 
hosts: cache files dns
passwd: cache files ldap

- check the bind with `id $some-ldap-user" for example.
- launch nscd (/etc/rc.d/nscd forcestart, for example)

1 - TEST top(1):
If your LDAP database is very small, you can tcpdump on port 389 or 636 to monitor the connection. You can also use ktrace on the top process, to see what's going on.
If your LDAP database is big (ours is 140 K records long), the top process will just hung a long time before displaying anything.

2 - TEST top(1) with the -u flag:
top -u should display its output immediately.

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list