[Dovecot] auth_user setting

[Timo Sirainen]

On 16.8.2004, at 11:23, Tom Metro wrote:

> 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.

The point is more about making sure that the untrusted login process 
can't go directly poking into trusted processes. Having login processes 
be able to ptrace() the auth process would be the worst case, but 
luckily both login and auth processes are treated as setuid processes 
so it's not allowed. But if they were running with same UIDs it'd be at 
least possible to let login process kill auth process. Not very nice 
either. I want to keep login processes in as restricted sandbox as 
possible.

> 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?

Looks like currently the config files are read as auth_user. I changed 
them now to be read before dropping privileges.

> 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.

Hmm. I guess it could be useful.

BTW. I'm pretty lazy at updating documentation. I finally changed most 
of the things you mentioned, but I wouldn't have minded if you had just 
changed them directly in Wiki :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://dovecot.org/pipermail/dovecot/attachments/20040828/5a6950ee/attachment-0001.bin>