[Dovecot] Multiple passdb/userdb ambiguity

[Alan Ferrency]

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 at 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 at example.com".

My solution adds "user=testguy at 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 at 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 at pair.com
>
>
>
>
>
>