On Fri, 29 Sep 2006, Peter Fern wrote:
Logan Shaw wrote:
So how can I be running this code and still experience the effects of an nss_ldap bug, even if there is one?
Is there a reason you're not just hitting LDAP directly?
The reason I started with dovecot going through getpwnam() and getspnam() is philosophical. Abstracting that so the configuration (and the implementation) is all in one place is the clean way to do things, and up until now there was no negative side to it.
But, I'm not so much of an idealist that I won't switch to LDAP if it's necessary to work around some bug that's causing mail to go to the wrong place. :-)
Still, I want to understand what's really going on. As I said, this problem happens rarely enough that it's hard for me to know empirically whether it's fixed, so the only route to knowing it's fixed is analytical. Now that I'm reading the exact code that dovecot uses to check the userdb, it's not clear to me that switching to LDAP will fix my problem. userdb-passwd.c explicitly checks for a wrong username back from getpwnam(), and the check doesn't appear to have fired[1], so how can it be that getpwnam() is returning wrong data?
- Logan
[1] Specifically, if getpwnam() returns a username that doesn't match what it was called with, dovecot calls i_fatal() whose output I assume will go to the log file. Since (a) the wrong messages got downloaded, and (b) I didn't see any "BROKEN NSS IMPLEMENTATION" message in the log file, I assume the check isn't firing.