[Dovecot] Postfix+Dovecot+LDAP

[Timo Sirainen]

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()).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20070315/1f04456b/attachment.pgp