I've had a look at the source of proftpd and it could be that using the PersistentPasswd option could help in this case, however LDAP users would not show up so it may not be an option for your environment.
Digging further I tracked the probable culprit to the ensure_open_passwd() function in mod_auth.c which does a dummy setpwent()/getpwent() call without endpwent() to try to ensure that the passwd file is open. This function is called from setup_env() which is called from auth_pass() which seems to be called for every authentication attempt. Attached is a patch that comments out the getpwent() part from ensure_open_passwd(). This should be sufficient for libnss-ldapd because it only starts a search on requesting the first result. Whether the original implementation really works as intended is questionable because it is not guaranteed that getpwnam() would use the same file that is used for getpwent(). The original goal of the function seems to be to be able to do name lookups after going into a chroot jail. An alternative is to do setpwent()/getpwent()/setpwent() which should abort the started search without wasting too much time trying to search LDAP entries in our environment. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong --
Description: Improve handling of getpwent calls This removes a dummy getpwent() call that causes problems with libnss-ldapd and large LDAP environments. Author: Arthur de Jong <adej...@debian.org> Bug-Debian: http://bugs.debian.org/717235 --- a/modules/mod_auth.c +++ b/modules/mod_auth.c @@ -830,8 +830,11 @@ static void ensure_open_passwd(pool *p) /* On some unices the following is necessary to ensure the files * are open. (BSDI 3.1) */ +/* Disabled this on Debian because it causes problems in large environments, + see http://bugs.debian.org/717235 pr_auth_getpwent(p); pr_auth_getgrent(p); +*/ } /* Next function (the biggie) handles all authentication, setting
signature.asc
Description: This is a digitally signed message part