[Dovecot] you got chocolate in my peanut butter?!

[Logan Shaw]

On Thu, 28 Sep 2006, /dev/rob0 wrote:
> On Thursday 28 September 2006 16:25, Logan Shaw wrote:
>> they ended up on.  So it would appear that, possibly, when this
>> user connected to the server, they got someone else's messages!
>> Messages that, in fact, came from an account they don't even
>> have the password to!

>> The accounts are all coming out of LDAP via nsswitch (and this
>
> Search the list archives (and the Red Hat bugzilla) for nss_ldap.
> There's your culprit.

Aha, that would appear to be it.  Thanks for the pointer.

To summarize what I've found since then, this is listed in
Redhat's bugzilla:

 	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154314
 	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154315

And it has been discussed before on this list:

 	http://www.dovecot.org/list/dovecot/2005-March/006345.html
 	http://www.dovecot.org/list/dovecot/2005-April/006859.html

But, I cannot find a bug related to this at the PADL nss_ldap
bugzilla:

 	http://bugzilla.padl.com/

So, it would appear that it hasn't been reported as the PADL
people, which would be helpful if it were to ever be fixed.
Unfortunately, I'm not sure I know enough about the problem
to create a useful bug report.

Still, I have to confess I'm a little confused about why
dovecot behaves the way it does.  When authenticating against
the results of a getpwnam() call, why take the name that it
returns when you already had the username in the first place?
Maybe I am missing something, but I can't see any advantage
in doing that.

Along the same lines, now suddenly I'm questioning whether
an incorrect username returned from getpwnam() (and nss_ldap)
really is the source of my problems.  In the version I'm using
(1.0.beta9), src/auth/userdb-passwd.c seems to already have
the workaround that checks for bogus NSS data:

         pw = getpwnam(auth_request->user);
         if (pw == NULL) { /* ... snip ... */ }

         if (strcasecmp(pw->pw_name, auth_request->user) != 0) {
                 /* try to catch broken NSS implementations (nss_ldap) */
                 i_fatal("BROKEN NSS IMPLEMENTATION: "
                         "getpwnam() lookup returned different user than was "
                         "requested (%s != %s).",
                         pw->pw_name, auth_request->user);
         }

And yet, I haven't seen that message in the logs, and since it
is a fatal error, it should prevent the session from proceding
(and the wrong mail messages from downloading) anyway, no?
So how can I be running this code and still experience the
effects of an nss_ldap bug, even if there is one?

   - Logan