Description of Problem:
When using nss_ldap for user and group lookup, each process that performs
lookups will end up with an extra file descriptor open (a TCP socket to the LDAP
server).  If those processes then spawn additional processes, the number of file
descriptors increments each time.

Although I'm not certain why, this causes the telnet client to fail once 10-20
file descriptors are used up in this fashion.  I'd suspect it places some burden
on the LDAP server as well, because of all the extra open sockets.

Although it may seem unlikely that processes would spawn enough children to
cause a problem, there are real world situations where processes can cascade
indefinitely.  Example: if you use VNC often and start new VNC sessions from old
VNC sessions, you pick up five or six new fds each time.  Another example: start
sshd from a "leaky" shell, then login through that sshd and start another shell.
 Rinse, wash, repeat: you should be able to leak a large number of fds this way.

Workaround: use nscd.  nscd should be mandatory when using nss_ldap.  (I wasn't
using it on one machine because RH6.2 had a nasty hang bug in nss_ldap/nscd (bug
19923).

Version-Release number of selected component (if applicable):
nss_ldap-172-2 (RH7.2 and earlier, I reproduced on RH6.2)

How Reproducible:
100% reproducible for me, but not many people run nss_ldap.  And most probably
run ncsd for the performance improvement.

Steps to Reproduce:
1. log in to a bash shell
2. Type "ls -l /proc/self/fd".
3. Type "bash" to spawn a new shell.
4. Repeat ls from step 2.
5. You should be able to see one more open file descriptor than before.
6. Repeat some more (i.e. spawn a third shell from within the second shell). 
Each new process inherits one additional file descriptor.