On Sun, 8 Oct 2006, Timo Sirainen wrote:
On Fri, 2006-09-29 at 11:11 -0500, Logan Shaw wrote:
[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.
I haven't before heard that this check wouldn't have caught the problem, but since I don't know what exactly the bug in nss_ldap is, I guess it's possible that sometimes the username is correct but the rest of the data (uid and home dir especially) isn't..
Yeah, that's possible, but can it cause this problem? I don't think a wrong home directory can cause this problem in my case, because I have the inboxes stored under /var/mail and I've verified that the wrong messages were present in a mailbox in /var/mail. So the home directory isn't involved.
So the other possibility is that it has something to do with the numeric uid. That would mean that dovecot is taking the username the user logs in with over the POP session, calling getpwnam() to get the uid, then calling getpwuid() (or something) later on to get the username back again. But I don't see getpwuid() anywhere in the code except in src/deliver/deliver.c, and I don't think deliver.c is related.
So, I'm still confused. :-) Does dovecot translate to numeric uid and then back again?
In any case, the only case when I've ever heard that user has had access to another user's mailbox accidentally is with nss_ldap, so I'm pretty sure that's the problem even if my check isn't working.
Yeah, there are definitely a lot of things pointing that direction. For one thing, it would be really impressive if dovecot could just come up with another valid username out of thin air. So it seems like it has to be getting it from the name service. But how?
- Logan