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=154315And 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.htmlBut, 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