dovecot - Jul 2013 - 2.2.4 - quota-status changing the user it is running as

Hello,

I'm currently experimenting with this quota-status service configuration:

	service quota-status {

		client_limit = 1
		executable = quota-status -p postfix
	
		# Let's make the default explicit.
		user = root

		unix_listener /var/spool/postfix/private/quota-policyd {

			user = postfix
		}
	}

The idea is to run the service as root during the preliminary tests (at worst,
since the service is going to be used as a policy daemon by Postfix only, it
shouldn't be very problematic to have it running as root anyway).

A user, with address john.doe at example.com and identified as john.doe, is
known to be over-quota.
A "doveadm quota get" returns:

	$ sudo doveadm quota get -u john.doe
	Password:
	Quota name        Type    Value Limit                                     %
	Quota utilisateur STORAGE     5     5                                   100
	Quota utilisateur MESSAGE     9     -                                     0

and messages for that user are correctly rejected by lmtp:

	dovecot[4989]: lmtp(5069, john.doe at example.com): QWSWLgrP4lF7FAAA5Q0ykw:
msgid=<20130714161643.9085DF176F2 at ALMba.local>: save failed to INBOX:
Quota exceeded (mailbox for user is full)

Let's now simulate a connection from Postfix:

	$ 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 '^]'.

A look at the output of top (excerpt) confirms that quota-status is running as
root:

	PID	COMMAND		UID
	5100	quota-status	0

Going on with our telnet session:

	recipient=john.doe at example.com
	size=10000

	action=OK


Hmmm... OK, this may be a config problem of mine which may require further
investigation.

Anyway, looking at top's output:

	PID	COMMAND		UID
	5100	quota-status	999

it appears that quota-status is now running as the mail_uid/mail_gid user; the
switch happens immediately after having entered the empty line in the telnet
session.

Let's then try to go further within the telnet session:

	recipient=john.doe at example.com
	size=10000

	action=DEFER_IF_PERMIT Internal error occurred. Refer to server log for more
information.

	^]
	telnet> quit
	Connection closed.

and a look at the log indeed reveals that quota-status doesn't have
sufficient privileges anymore:

	dovecot[4989]: quota-status(john.doe at example.com): Error: user john.doe at
example.com: Error reading configuration:
net_connect_unix(/_ROOT/var/run/dovecot/config) failed: Permission denied

Is this the expected behavior, to have quota-status switch to another user?

TIA,
Axel

Le 14 juil. 2013 ? 18:54, Axel Luttgens a ?crit :
> [...]
> 
> Is this the expected behavior, to have quota-status switch to another user?
I should have added: "And to have it indefinitely running as that
user?".

Notwithstanding the permission problems that come with that behavior (see my
previous post), this doesn't seem to be fully right for a service intended
to be a policy server for Postfix.

For example, let's consider the case of separate uid (or even uid/gid) for
mail users.
Suppose that the initial connection to quota-status happens for checking quota
of user with uid 10001; if quota-status is configured to start as root, we know
it will switch to user 10001 and stay running under that uid.
Later, a query comes from Postfix for the quota of user with uid 100002.
Unless quota-status hasn't fully dropped its root privileges but has just
switched to user 10001 while still having the capability to switch to user
10002, I guess there could be a problem...

How exactly is quota-status supposed to behave in such a case?

TIA,
Axel

On 14.7.2013, at 19.54, Axel Luttgens <AxelLuttgens at swing.be> wrote:
> and messages for that user are correctly rejected by lmtp:
> 
> 	dovecot[4989]: lmtp(5069, john.doe at example.com):
QWSWLgrP4lF7FAAA5Q0ykw: msgid=<20130714161643.9085DF176F2 at ALMba.local>:
save failed to INBOX: Quota exceeded (mailbox for user is full)
> 
> Going on with our telnet session:
> 
> 	recipient=john.doe at example.com
> 	size=10000
> 
> 	action=OK
> 
> Hmmm... OK, this may be a config problem of mine which may require further
investigation.
Did you solve this?
> and a look at the log indeed reveals that quota-status doesn't have
sufficient privileges anymore:
> 
> 	dovecot[4989]: quota-status(john.doe at example.com): Error: user john.doe
at example.com: Error reading configuration:
net_connect_unix(/_ROOT/var/run/dovecot/config) failed: Permission denied
> 
> Is this the expected behavior, to have quota-status switch to another user?
Either one of these fixes would be sufficient:

http://hg.dovecot.org/dovecot-2.2/rev/2470bb9106b0
http://hg.dovecot.org/dovecot-2.2/rev/51b8020b29f6

Yet another possibility would be to use service { service_count=1 } to recreate
the process every time.