[Dovecot] Multiple passdb/userdb ambiguity

[Alan Ferrency]

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 at pair.com