On Mon, 10 Sep 2007, Timo Sirainen wrote:
On Mon, 2007-09-10 at 11:42 -0400, Alan Ferrency wrote:
(Snip: I use userdb prefetch and a bunch of userdb_* settings in the passdb file, and Timo suggested it was not necessary. I then recalled an incorrect explanation for why I might have done this...)
I think this may have been related to file permissions: we didn't want to give all users read access to the userdb file after they've logged in, and prefetching allowed us to limit access to only the login/auth user. Running an smtpauth port for deliver kind of makes that a moot point anyway, though, so maybe we can clean things up a bit.
Only dovecot-auth process accesses the userdb file.
I now remember (rediscovered) why I had to use userdb prefetch in our setup.
I'm using multiple passdb passwd-file files, one of which provides local IP based virtual mail hosting. Usernames are not guaranteed to be unique across both files.
If I use userdb passwd-file with the same two files, then sometimes the wrong userdb information will be used. If I log in to a username which is in both the first and second passdb file, and use the password for the second passdb's version of the username, it will log in correctly but use the username's userdb information in the _first_ userdb file that matches (instead of the second).
This is, needless to say, Very Bad. I fixed it using userdb prefetch, but I would prefer a better solution.
In this case, our preferred behavior is unambiguous, but I couldn't figure out how to configure it. If the username exists in the first passdb, but the incorrect password is used, login should be denied, instead of checking the second passdb file. The second passdb should only be used if the username doesn't exist in the first passdb.
This would avoid the possibility of accidentally using the second passdb for login, but the first userdb file for user information, and would remove ambiguity from setups such as ours.
Is the current behavior considered correct? Is this configurable to do what I need instead? I didn't find anything addressing it in the wiki.
Thanks,
Alan Ferrency pair Networks, Inc. alan@pair.com