Bug 161456

Summary: [libpam] on a system bound to an LDAP server, top tries to get the whole LDAP content to resolve uids
Product: Base System Reporter: Patrick Proniewski <patpro>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Open ---    
Severity: Affects Only Me    
Priority: Normal    
Version: 7.3-RELEASE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
smime.p7s none

Description Patrick Proniewski 2011-10-10 10:30:10 UTC
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.
Comment 1 cgrosjean 2012-03-09 10:13:53 UTC
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    Actually,<br>
    <br>
    A fix would consist in having a parameter (or such like option) on
    the FreeBSD side to decide wether or not to send a LDAP paged result
    control.<br>
    This way, FreeBSD 'd be able to accomodate against any kind of LDAP
    (or LDAP proxy) server configuration.<br>
    <br>
    <div class="moz-signature">-- <br>
      <meta http-equiv="CONTENT-TYPE" content="text/html;
        charset=ISO-8859-1">
      <title>signature</title>
      <meta name="GENERATOR" content="OpenOffice.org 2.2 (Linux)">
      <meta name="CREATED" content="16010101;0">
      <meta name="CHANGED" content="16010101;0">
      <style type="text/css">
	<!--
		TD P { color: #000000 }
		P { color: #000000 }
		A:link { color: #0000ff }
		A:visited { color: #ff0000 }
	--></style><br>
    </div>
  </body>
</html>
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:05 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped