[Dovecot] auth_user setting

[Tom Metro]

Timo Sirainen wrote:
> I wrote a page about this in 
> http://wiki.dovecot.org/moin.cgi/UserIds

Quoting from http://wiki.dovecot.org/moin.cgi/UserIds:
> 2. Dovecot user
> dovecot user...is only used while Dovecot is processing user logins
[...]
> 5. Authentication process UID
> auth_user setting...only specifies the UID under which dovecot-auth
> process is run. ...you might want to create a separate dovecot-auth
> user to use here if you're not authenticating with PAM or shadow file
> which require roots.

This and other documentation seems to suggest that the 'dovecot' user ID 
shouldn't be reused as the auth_user setting. But based on how you have 
described the purpose of the two IDs, they appear to be serving a 
similar purpose, and thus it might make sense to use the same ID.

Could you clarify in the documentation whether this is an acceptable 
practice, or if not, why?

A scenario in which I could see there being an advantage is one in which 
the network process (running as 'dovecot') is compromised, and the 
hacker would then be unable to access the password database due to it 
providing access only to the UID specified by auth_user. Although it 
seems that additional security steps are really necessary in order for 
that to be true. In a typical SQL database setup, the database won't 
enforce system UID access restrictions, so it'll be up to the 
administrator to make sure the Dovecot database configuration file (say 
dovecot-mysql.conf) is not generally readable.

Which raises the question, how restrictive can permissions be on those 
configuration files? Are they read by Dovecot while root? Or will they 
be read by the authentication process while running as auth_user? If 
they can be readable only by root, and the administrator takes advantage 
of that, then it seems there would be little advantage for
auth_user != login_user because any non-root account wouldn't be able to 
  read the config file.

I see my dovecot-mysql.conf is world readable. Oops. Probably not a good 
thing, given it contains a MySQL password in clear text. You might want 
to put a security check into the code somewhere for that, in the same 
way it is common for MTAs to check on the permissions of files they 
depend on.

  -Tom