I wrote:
If I use userdb passwd-file with the same two files, then sometimes the wrong userdb information will be used.
Shortly after reporting this issue, I came across two configuration solutions for my problem (please read below for details). I haven't tested the first one yet:
Assume I have the current passdb setup:
passdb passwd-file { args = <snip>/%l.passwd } passdb passwd-file { args = <snip>/virtual.passwd }
One way to make it impossible to log in to usernames found in %l.passwd if the password doesn't match %l.passwd is to add a "deny" passdb:
passdb passwd-file { args = <snip>/%l.passwd } passdb passwd-file { args = <snip>/%l.passwd deny = yes } passdb passwd-file { args = <snip>/virtual.passwd }
This seems like it should allow users in %l.passwd to log in, but if the password doesn't match, they'll be denied before an ambiguous username/password in virtual.passwd is tried.
The solution I settled on, and which I confirmed works for my setup, is to set the "user=" field in %l.passwd to change IP-based virtual usernames into fully qualified usernames, and then only use virtual.passwd for all userdb lookups.
For example, consider username "testguy" in %l.passwd, which also exists in virtual.passwd. In all cases, for virtual user testguy@example.com, I set up a %l.passwd entry for "testguy" with example.com's IP, and also an entry in virtual.passwd for "testguy@example.com".
My solution adds "user=testguy@example.com" to testguy's passwd-file entry in %l.passwd file.
Now, I can stop using %l.passwd as a userdb file, and all userdb info for virtual users will be looked up by the fully qualified username in virtual.passwd. There is no ambiguity when a non-virtual user logs in, because the per-IP names are always looked up with their canonical domain even if they match system usernames.
Thanks for your time, Alan Ferrency pair Networks, Inc. alan@pair.com
On Thu, 13 Sep 2007, Alan Ferrency wrote:
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