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 [EMAIL PROTECTED], I
set up a %l.passwd entry for "testguy" with example.com's IP, and also
an entry in virtual.passwd for "[EMAIL PROTECTED]".
My solution adds "[EMAIL PROTECTED]" 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.
[EMAIL PROTECTED]
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.
> [EMAIL PROTECTED]
>
>
>
>
>
>
