On Thu, 2007-03-15 at 10:58 -0700, Troy Engel wrote:
Timo Sirainen wrote:
Yes, http://wiki.dovecot.org/PasswordDatabase/PAM explains what it does and why it might not be a good idea. Although no-one has yet reported any success/failure stories, those are all my own guesses..
I gotcha, makes sense having read it. Now I'm back on the fence, as I'll want to research the status of these PAM/nss_ldap memory leaks that might occur if we set it to blocking=yes.
blocking=yes doesn't break anything with nss_ldap, since without blocking=yes it'll run in one process anyway. PAM works differently.
It seems like the choice is to be asynchronous and possibly run into a user collision on the file descriptor (percentage chance, anyone? 2%? 5%?) or to use a synchronous/blocking pipeline at the expense of never releasing the PAM code (sic) and possibly leaking memory.
You're somehow mixing up these things. :) Probably because of the "blocking" naming, which actually does the opposite of what it's named.. Hmm. I guess it's too late to rename it, but I could update the wiki. My thought process went like "blocking=yes tells Dovecot that the passdb/userdb does blocking lookups, and it should do something about it so that the calls don't block everything else".
Here are the possible combinations and how they work:
blocking=yes pam, blocking=yes nss_ldap: Potential memory leaks. Fixes nss_ldap problems. Dovecot creates multiple worker processes to execute both the NSS and the PAM lookups. It increases the worker process count if all of them are busy, so it's not really synchronous/blocking.
blocking=no pam, blocking=yes nss_ldap: No memory leaks leaks. Fixes nss_ldap problems. Each PAM lookup is done in a forked process. NSS lookups are done in auth worker processes, as described above. So again no lookup blocks others.
blocking=yes pam, blocking=no nss_ldap: Potential memory leaks. Should also fix nss_ldap problems. Each NSS lookup is synchronous, so they are blocking everything else.
blocking=no pam, blocking=no nss_ldap: NSS lookups are blocking, and nss_ldap is broken.
Here comes my "I am not a real programmer" thought -- there really is no way for dovecot-auth's forked child processes to set up their own unique descriptor? Maybe an alternative way of doing the fork? Just pondering...
In the blocking=no case, there's no way to release the existing LDAP connection without exec()ing another binary which gets rid of the internal state. That's a bug in nss_ldap I think, it should close the LDAP connection when forking (since it's not closing it in endpwent()).