dovecot - Jul 2013 - 2.2.4 - Some questions about and needing help with quota-status

Help! I'm stuck. :-(

The config of my experimental setup appears at the end of this message; I'm
providing hereafter some more info that may not be immediately obvious.

This is dovecot 2.2.4 with changesets 9091d0f2d971 and 2be295a0b64f.

All involved databases are sqlite ones.

passdb and userdb are devised so as to change usernames.
For example, I could have a user with addresses "doe at
oldexample.com", "johnd at oldexample.com" and "john.doe at
example.com" needing to be able to log in as "jdoe" or
"u123456"; all db lookups for that user then end with name
"john.doe".

This is a single mail user setup (user/group "dovemailer", uid/gid
999).

Service lmtp has been configured to run as that user; that required a slight
adjustment at the auth-userdb socket level.

As a general rule, the quota dict appears to be correctly updated upon message
arrivals and removals (thru lmtp, pop, imap), and to be correctly
queried/interpreted by the various parts of the server.

For example, thru the userdb query, user john.doe has been given an even lower
quota limit than the already low default defined for testings:

	$ sudo doveadm quota get -u john.doe
	Quota name        Type    Value Limit                   %
	Quota utilisateur STORAGE    20     5                 400
	Quota utilisateur MESSAGE    14     -                   0

and is clearly recognized as being over-quota by lmtp:

	$ telnet /_ROOT/var/run/dovecot/lmtp
	Trying /_ROOT/var/run/dovecot/lmtp...
	Connected to (null).
	Escape character is '^]'.
	220 almba.local Dovecot ready.
	mail from:<mary.jane at example.com>
	250 2.1.0 OK
	rcpt to:<john.doe at example.com>
	250 2.1.5 OK
	data
	354 OK
	Subject: test
	
	.
	552 5.2.2 <john.doe at example.com> Quota exceeded (mailbox for user is
full)

Note that both services config and dict are launched if they aren't running.

Since it has been previously seen that running quota-status as root comes with
its own problems, and since it is a single user setup anyway, I'm trying to
run it as dovemailer as well.

So, let's try to see what quota-status thinks about john.doe:

	$ sudo -u _postfix telnet /_ROOT/var/spool/postfix/private/quota-policyd
	Trying /_ROOT/var/spool/postfix/private/quota-policyd...
	Connected to (null).
	Escape character is '^]'.
	Connection closed by foreign host.

Clearly, not much...
Looking in the log:

	dovecot[10554]: quota-status: Fatal: Error reading configuration:
net_connect_unix(/_ROOT/var/run/dovecot/config) failed: Permission denied

This thus raises a first question:

Q1. What makes lmtp and quota-status different? How does lmtp manage to fetch
all needed info, while quota-status seems to require an access to the config
socket?

Let's then slightly adjust dovecot.conf, in the hope to make quota-status
happy:

	service config {
		unix_listener config {
			group = dovemailer
			mode = 0660
		}
	}

Q2. Should the above really be needed, wouldn't there be a better way?

I ask, because it seems to me that I'm starting to seriously lose the
benefits of privilege separation...

Anyway, let's ask quota-status again:

	$ sudo -u _postfix telnet /_ROOT/var/spool/postfix/private/quota-policyd
	Password:
	Trying /_ROOT/var/spool/postfix/private/quota-policyd...
	Connected to (null).
	Escape character is '^]'.
	recipient=john.doe at example.com
	size=10000

	action=OK

	^]
	telnet> quit
	Connection closed.

In the log:

	dovecot[11050]: auth: Debug: userdb out: USER	1	john.doe at example.com
quota_rule=*:storage=5k
	dovecot[11050]: quota-status: Debug: auth input: john.doe at example.com
quota_rule=*:storage=5k
	dovecot[11050]: quota-status: Debug: Added userdb setting:
plugin/quota_rule=*:storage=5k
	dovecot[11050]: quota-status(john.doe at example.com): Debug: Effective
uid=999, gid=999, home=/_Mailstores/john.doe
	dovecot[11050]: quota-status(john.doe at example.com): Debug: Quota root:
name=Quota utilisateur backend=dict args=john.doe:proxy::sql_quota
	dovecot[11050]: quota-status(john.doe at example.com): Debug: Quota rule:
root=Quota utilisateur mailbox=* bytes=5120 messages=0
	dovecot[11050]: quota-status(john.doe at example.com): Debug: Quota grace:
root=Quota utilisateur bytes=512 (10%)
	dovecot[11050]: quota-status(john.doe at example.com): Debug: dict quota:
user=john.doe, uri=proxy::sql_quota, noenforcing=0
	dovecot[11050]: quota-status(john.doe at example.com): Debug: fs:
root=/_Mailstores/john.doe/mboxes, index=, indexpvt=, control=,
inbox=/_Mailstores/john.doe/mboxes/inbox, alt
It is to be noted that the config server is now launched as expected, but that
the dict server still isn't.

Trying a dirsize backend instead of the dict backend doesn't help.

The problem seems to be circumscribed to the interaction with the quota backend
since, for example, querying quota-status for an unknown recipient yields an
expected "action=REJECT Unknown user".

Hence my last question, after having tried a lot of things for several days now,
with no more success:

Q3. What am I doing wrong?

Many thanks in advance,
Axel


# 2.2.4: /_ROOT/etc/dovecot/dovecot.conf
# OS: Darwin 12.4.0 x86_64  
auth_debug = yes
dict {
 sql_quota = sqlite:/_ROOT/etc/dovecot/dict-quota.conf
}
disable_plaintext_auth = no
listen = *
mail_debug = yes
mail_gid = dovemailer
mail_home = /_Mailstores/%n
mail_location = mbox:~/mboxes:INBOX=~/mboxes/inbox
mail_plugins = quota
mail_uid = dovemailer
managesieve_sieve_capability = vacation
mbox_write_locks = fcntl
passdb {
 args = /_ROOT/etc/dovecot/db.conf
 driver = sql
}
plugin {
 quota = dict:Quota utilisateur:%n:proxy::sql_quota
 quota_rule = *:storage=50M
 sieve = ~/sieve/active_script.sieve
 sieve_dir = ~/sieve/scripts
 sieve_extensions = vacation
 sieve_max_actions = 3
 sieve_max_redirects = 2
 sieve_max_script_size = 10K
 sieve_user_log = ~/sieve/log
}
service auth {
 unix_listener auth-userdb {
   group = dovemailer
   mode = 0660
   user = $default_internal_user
 }
}
service dict {
 unix_listener dict {
   group = dovemailer
   mode = 0660
 }
}
service lmtp {
 group = dovemailer
 user = dovemailer
}
service quota-status {
 client_limit = 1
 executable = quota-status -p postfix
 group = dovemailer
 unix_listener /_ROOT/var/spool/postfix/private/quota-policyd {
   user = _postfix
 }
 user = dovemailer
}
ssl = no
userdb {
 driver = prefetch
}
userdb {
 args = /_ROOT/etc/dovecot/db.conf
 driver = sql
}
protocol lmtp {
 mail_plugins = quota sieve
 postmaster_address = postmaster at example.com
 sendmail_path = /_ROOT/postfix/sbin/sendmail
}
protocol pop3 {
 pop3_uidl_format = %08Xv%08Xu
}

Hello,

I ended my previous message with :
> [...]
> Q3. What am I doing wrong?
> [...]
Given the details discussed in another thread
(http://www.dovecot.org/list/dovecot/2013-July/091309.html), I tried by changing
the user_query's SELECT from:

	user_query = \
	SELECT DISTINCT \
		nickname AS user, \
		mail_home AS home, \
		mail_location AS mail, \
		quota_rule AS quota_rule \
	FROM \
	[...]

to:

	user_query = \
	SELECT DISTINCT \
		nickname AS user, \
		coalesce(mail_home, '/_Mailstores/' || nickname) AS home, \
		mail_location AS mail, \
		'dict:Quota utilisateur:' || nickname || ':proxy::sql_quota'
AS quota, \
		quota_rule AS quota_rule \
	FROM \
	[...]

while keeping dovecot.conf unchanged (see my previous message).

The idea is to not rely anymore on the expansion of %u (or %n or %d) in
dovecot.conf, while still keeping the ability to have per-user settings.

Currently, a doveadm quota get -u john.doe yields:

	Quota name        Type    Value Limit               %
	Quota utilisateur STORAGE    31    34              91
	Quota utilisateur MESSAGE    23     -               0

So, let's ask quota-status what it believes about a message with a size of
100000.

The reply is still "action=OK", the dict server still isn't
launched, and the log shows:

	auth: Debug: userdb out: USER	1	john.doe at example.com
home=/_Mailstores/john.doe	quota=dict:Quota
utilisateur:john.doe:proxy::sql_quota	quota_rule=*:storage=35000b
	quota-status: Debug: auth input: john.doe at example.com
home=/_Mailstores/john.doe quota=dict:Quota
utilisateur:john.doe:proxy::sql_quota quota_rule=*:storage=35000b
	quota-status: Debug: Added userdb setting: plugin/quota=dict:Quota
utilisateur:john.doe:proxy::sql_quota
	quota-status: Debug: Added userdb setting: plugin/quota_rule=*:storage=35000b
	quota-status(john.doe at example.com): Debug: Effective uid=999, gid=999,
home=/_Mailstores/john.doe
	quota-status(john.doe at example.com): Debug: Quota root: name=Quota
utilisateur backend=dict args=john.doe:proxy::sql_quota
	quota-status(john.doe at example.com): Debug: Quota rule: root=Quota
utilisateur mailbox=* bytes=35000 messages=0
	quota-status(john.doe at example.com): Debug: Quota grace: root=Quota
utilisateur bytes=3500 (10%)
	quota-status(john.doe at example.com): Debug: dict quota: user=john.doe,
uri=proxy::sql_quota, noenforcing=0
	quota-status(john.doe at example.com): Debug: fs:
root=/_Mailstores/john.doe/mboxes, index=, indexpvt=, control=,
inbox=/_Mailstores/john.doe/mboxes/inbox, alt
To rule out any other side-effects potentially introduced by the user_query, I
even tried with the "nickname AS user" removed from the SELECT.

Even with that, the reply is "action=OK", the dict server still
isn't launched, and the lines written to the log are undistinguishable from
above ones...

It is to be noted that no lines in the log are related to possible problems
encountered for launching it. It is a bit as if quota_check() in
src/plugins/quota/quota-status.c always immediately returned with 1 at the first
test.

Anyway, I'm still stuck.
And still very interested in replies to Q1, Q2 and Q3. ;-)

TIA,
Axel