This documentation is for Dovecot v1.x, see wiki2 for v2.x documentation.

System users used by Dovecot

Dovecot typically requires 3 or more system users:

Using multiple users allows privilege separation, which makes it harder for attackers to compromise the whole system if a security hole is found from one component. However, if you really want to run everything under a single user, it's possible.

Dovecot user

dovecot user is used internally for processing users' logins. It shouldn't have access to any files, authentication databases or anything else either. It should belong to its own private dovecot group where no one else belongs to, and which doesn't have access to any files either (other than what Dovecot internally creates).

dovecot user isn't used for any kind of mail processing - don't store users' mails as dovecot, and don't put dovecot user to mail or any other groups.

You can change the default dovecot user to something else from login_user setting.

Mail users

You can use one or more system users for accessing users' mails. Most configurations can be placed to two categories:

  1. System users where each Dovecot user has their own system user in /etc/passwd. For system user setups you generally don't have to worry about UIDs or GIDs.

  2. Virtual users where all Dovecot users run under a single system user, for example vmail (just NOT dovecot).

However it's possible to use a setup that is anything between these two. For example use a separate system user for each domain.

UIDs

Dovecot's user database configuration calls system users UIDs. There are a few things you should know about them:

GIDs

System groups (GIDs) work very much the same way as UIDs described above: You can use names instead of numbers for GID values, and the used GIDs don't have to exist in /etc/group.

System groups are useful for sharing mailboxes between users that have different UIDs but belong to a same group. Currently Dovecot doesn't try to do anything special with the groups, so if you're not sure how you should create them, you might as well place all the users into a single group or create a separate group for each user.

If you use multiple UIDs and you wish to create shared mailboxes, setting up the groups properly may make your configuration more secure. For example if you have two teams and their mailboxes are shared only to their team members, you could create a group for each team and set the shared mailbox's group to the team's group and permissions to 0660, so neither team can even accidentally see each others' shared mailboxes.

Currently Dovecot supports specifying only the primary group, but if your userdb returns system_user extra field, the non-primary groups are taken from /etc/group for that user. In a future version the whole GID list will be configurable without help from /etc/group.

It's also possible to give all the users access to extra groups with mail_access_groups setting.

Authentication process user

auth default {
  ..
  user = root
}

The auth user setting specifies the system user under which dovecot-auth processes are run. The user must have access to your password databases and user databases. It's not used for anything else. The default is to use root, because it's guaranteed to have access to all the password databases. The user must not be the same as login_user (dovecot).

If you're using a virtual user setup, there's really no reason for you to use root. You could instead create a new auth user, such as doveauth. If you're using SQL or LDAP the user doesn't need access to any of Dovecot's configuration files, because they're read while Dovecot is still running as root.

PAM and shadow passdbs are usually configured to read /etc/shadow file. Even this doesn't need root access if you give the auth user access to shadow group, and make sure that the /etc/shadow file is readable by the shadow group.

UserIds (last edited 2010-05-31 19:42:09 by TimoSirainen)