dovecot - Jul 2013 - Ambiguous behavior with prefetch database?

Hello,

Let's say dovecot.conf contains:

	mail_uid	= dovemailer
	mail_gid	= dovemailer
	mail_home	= /some/path/%n
	mail_location	= mbox:~/mboxes:INBOX=~/mboxes/inbox

and that the password database query is of the form:

	password_query = \
	SELECT \
		passwd AS password, \
		nickname AS user, \
		mail_home AS userdb_home, \
		mail_location AS userdb_mail, \
	WHERE \
		...

The database initially comes with NULL for both mail_home and mail_location, the
goal being to be able to progressively replace legacy settings.

With the above, one gets such entries in the logs upon a pop or imap connection:

	auth-worker(11262): Debug: auth(u12345678,127.0.0.1): username changed
u12345678 -> john.doe
	auth: Debug: auth(u12345678,127.0.0.1,<dsNsasbgRQB/AAAB>): username
changed u12345678 -> john.doe
	[...]
	auth: Debug: prefetch(john.doe,127.0.0.1,<dsNsasbgRQB/AAAB>): passdb
didn't return userdb entries, trying the next userdb

and, of course, the userdb_query fails since it isn't supposed to be invoked
under such circumstances.

Of course, the userdb_query could be adapted so as to handle pop/imap
connections in addition to say, lmtp or doveadm connections, but this would
anyway raise the question: why bother with a prefetch database setup?

In fact, it seems that the problem comes from the fact that the password_query
returns NULL values (i.e. "do not override dovecot.conf settings") for
all userdb_xxx settings even if, technically speaking, it returns such columns.

A slight yet somewhat silly modification of the password_query, such as this
one:

	password_query = \
	SELECT \
		passwd AS password, \
		nickname AS user, \
		'dovemailer' AS userdb_uid, \
		mail_home AS userdb_home, \
		mail_location AS userdb_mail, \
	WHERE \
		...

indeed seems to bring back all the expected behavior: now, the "passdb
returns userdb entries" and, for example, the config's mail_home
expands to the expected value /some/path/john.doe.

Could it be that the case "userdb_xxx columns returned, even if all with
NULL values" has been somehow overlooked in the code?
Or am I erring with my interpetation of all those matters?

TIA,
Axel

Fixed: http://hg.dovecot.org/dovecot-2.2/rev/9091d0f2d971

And for LDAP: http://hg.dovecot.org/dovecot-2.2/rev/939aa051e3f1

On 6.7.2013, at 1.18, Axel Luttgens <AxelLuttgens at swing.be> wrote:
> Hello,
> 
> Let's say dovecot.conf contains:
> 
> 	mail_uid	= dovemailer
> 	mail_gid	= dovemailer
> 	mail_home	= /some/path/%n
> 	mail_location	= mbox:~/mboxes:INBOX=~/mboxes/inbox
> 
> and that the password database query is of the form:
> 
> 	password_query = \
> 	SELECT \
> 		passwd AS password, \
> 		nickname AS user, \
> 		mail_home AS userdb_home, \
> 		mail_location AS userdb_mail, \
> 	WHERE \
> 		...
> 
> The database initially comes with NULL for both mail_home and
mail_location, the goal being to be able to progressively replace legacy
settings.
> 
> With the above, one gets such entries in the logs upon a pop or imap
connection:
> 
> 	auth-worker(11262): Debug: auth(u12345678,127.0.0.1): username changed
u12345678 -> john.doe
> 	auth: Debug: auth(u12345678,127.0.0.1,<dsNsasbgRQB/AAAB>): username
changed u12345678 -> john.doe
> 	[...]
> 	auth: Debug: prefetch(john.doe,127.0.0.1,<dsNsasbgRQB/AAAB>): passdb
didn't return userdb entries, trying the next userdb
> 
> and, of course, the userdb_query fails since it isn't supposed to be
invoked under such circumstances.
> 
> Of course, the userdb_query could be adapted so as to handle pop/imap
connections in addition to say, lmtp or doveadm connections, but this would
anyway raise the question: why bother with a prefetch database setup?
> 
> In fact, it seems that the problem comes from the fact that the
password_query returns NULL values (i.e. "do not override dovecot.conf
settings") for all userdb_xxx settings even if, technically speaking, it
returns such columns.
> 
> A slight yet somewhat silly modification of the password_query, such as
this one:
> 
> 	password_query = \
> 	SELECT \
> 		passwd AS password, \
> 		nickname AS user, \
> 		'dovemailer' AS userdb_uid, \
> 		mail_home AS userdb_home, \
> 		mail_location AS userdb_mail, \
> 	WHERE \
> 		...
> 
> indeed seems to bring back all the expected behavior: now, the "passdb
returns userdb entries" and, for example, the config's mail_home
expands to the expected value /some/path/john.doe.
> 
> Could it be that the case "userdb_xxx columns returned, even if all
with NULL values" has been somehow overlooked in the code?
> Or am I erring with my interpetation of all those matters?
> 
> TIA,
> Axel
>