This documentation is for Dovecot v2.x, see wiki1 for v1.x documentation.
Differences between revisions 8 and 19 (spanning 11 versions)
Revision 8 as of 2009-03-15 22:35:22
Size: 4692
Editor: localhost
Comment: converted to 1.6 markup
Revision 19 as of 2019-03-21 07:18:09
Size: 4536
Editor: AkiTuomi
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

The main purpose of login processes is to handle the IMAP and POP3 connections before the user has logged in. The login processes don't need to be able to do anything else than let the user log in, so they can run in highly restricted environment. By default they are run as a non-privileged "dovecot" user chrooted into a non-writable directory containing only authentication UNIX sockets.
The main purpose of login processes is to handle the IMAP, POP3, [[Submission]] (v2.3), and [[Pigeonhole/ManageSieve|ManageSieve]] connections before the user has logged in. The login processes don't need to be able to do anything else than let the user log in, so they can run in highly restricted environment. By default they are run as a non-privileged "dovenull" user chrooted into a non-writable directory containing only authentication UNIX sockets.
Line 9: Line 8:
== Login process creation ==

{{{login_processes_count}}} and {{{login_max_processes_count}}} setting control how new login processes are created. {{{login_processes_count}}} specifies the number of login processes that are tried to be kept listening for new connections. However when a lot of connections arrive at the same time this number will increase automatically as described below.

To prevent fork-bombing Dovecot's login process creation works in a similiar way to Apache: Initially set "wanted listening process count" to same as {{{login_processes_count}}} and start the processes. Then check every second if we need to start up new processes to keep the listening process count the same as the wanted count. If all the listening processes have been used, double the wanted count. If we haven't used all of them, decrease the wanted count by one (unless it goes below {{{login_processes_count}}}), but don't destroy already created processes. {{{login_max_processes_count}}} specifies the maximum number of login processes there can exist at a time (listening, non-listening and SSL/TLS-proxying processes combined).
For explanation on the various settings for services, see [[Services]]
Line 16: Line 11:
You can enable high-security mode with:
Line 17: Line 13:
Setting {{{login_process_per_connection=yes}}} enables the high-security mode. This is the default. It works by using a new imap-login or pop3-login process for each incoming connection. Since the processes run in a highly restricted chroot, running each connection in a separate process means that in case there is a security hole in Dovecot's pre-authentication code or in the SSL library, the attacker can't see other users' connections and can't really do anything destructive. {{{
service imap-login {
  service_count
= 1
  #process_min_avail = 0
  #process_limit = $default_process_limit
  #vsz_limit = 64M
}
service pop3-login {
  service_count = 1
}
}}}
This is the default. It works by using a new imap-login or pop3-login process for each incoming connection. Since the processes run in a highly restricted chroot, running each connection in a separate process means that in case there is a security hole in Dovecot's pre-authentication code or in the SSL library, the attacker can't see other users' connections and can't really do anything destructive. The only way out of it is to find and exploit a kernel security hole.
Line 19: Line 26:
Since one login process can handle only one connection, {{{login_max_processes_count}}} limits the number of users that can be logging in at the same time. Currently SSL/TLS proxying processes are also counted here, so if you're using SSL/TLS you'll need to make sure this count is higher than the maximum number of users that can be logged in simultaneously. Since one login process can handle only one connection, the service's {{{process_limit}}} setting limits the number of users that can be logging in at the same time (defaults to {{{default_process_limit=100}}}). SSL/TLS proxying processes are also counted here, so if you're using SSL/TLS you'll need to make sure this count is higher than the maximum number of users that can be logged in simultaneously. With TLS/SSL connections, the login process will not terminate, and remains to perform proxying between imap backend process and the client.
Line 21: Line 28:
If the maximum login process count is reached, the oldest process in logging-in state (ie. non-proxying) is destroyed.

{{{login_max_connections}}} setting is completely ignored in this mode.

{{{login_process_size
}}} should be fine at its default 32MB value.
 * If the maximum login process count is reached, the oldest process in logging-in state (ie. non-proxying) is destroyed.
 * To avoid startup latency for new client connections, set {{{process_min_avail}}} to higher than zero. That many idling processes are always kept around waiting for new connections.
 * {{{vsz_limit}}} should be fine at its default 64MB value.
Line 28: Line 33:
You can enable high-performance mode with:
Line 29: Line 35:
Setting {{{login_process_per_connection=no}}} enables the high-performance mode. It works by using a number of long running login processes, each handling a number of connections. This loses much of the security benefits of the login process design, because in case of a security hole the attacker is now able to see other users logging in and steal their passwords. {{{
service imap-login {
  service_count = 0
  #client_limit = $default_client_limit
  process_min_avail = 4 # number of CPU cores
  vsz_limit = 1G
}
service pop3-login {
  service_count = 0
}
}}}
It works by using a number of long running login processes, each handling a number of connections. This loses much of the security benefits of the login process design, because in case of a security hole (in Dovecot or SSL library) the attacker is now able to see other users logging in and steal their passwords, read their mails, etc.
Line 31: Line 48:
Login process creation rules apply just the same for this mode, but a process is counted as "non-listening" only when it's handling {{{login_max_connections}}} connections already. So a new login process is created only when one of the existing ones has used up all its connections and gone into non-listening state. The maximum number of users logging in at the same time (+ SSL/TLS proxying connections) is {{{login_max_connections}}} * {{{login_max_processes_count}}}.  * {{{process_min_avail}}} should be set to be at least the number of CPU cores in the system, so that all of them will be used.
 * Otherwise new processes are created only once an existing one's connection count reaches client_limit
 * Default client_limit * process_limit = 1000*100 = 100k connections
 * vsz_limit should be increased to avoid out of memory errors, especially if you're using SSL/TLS.
Line 33: Line 53:
You should make sure that the process has at least 16 + {{{login_max_connections}}} * 2 available file descriptors. v1.1+ checks this at startup and warns if you don't have enough fds available. == Login access check sockets ==
Line 35: Line 55:
If you're using SSL/TLS you might want to increase the {{{login_process_size}}}. With the default 32MB Dovecot itself should be able to handle a few thousand connections, but SSL libraries might require more. Dovecot login processes can check via UNIX socket if the incoming connection should be allowed to log in. This is most importantly implemented to enable TCP wrappers support for Dovecot.
Line 37: Line 57:
The number of login processes should be about the same as the number of CPUs on your system. So {{{login_max_connections}}} should be much higher than {{{login_processes_count}}}. === TCP wrappers support ===
You must have built Dovecot with support for TCP wrappers. You can do this by giving {{{--with-libwrap}}} parameter to {{{configure}}}.

Add to dovecot.conf:
{{{
login_access_sockets = tcpwrap

service tcpwrap {
  unix_listener login/tcpwrap {
    group = $default_login_user
    mode = 0600
    user = $default_login_user
  }
}
}}}

Remember to configure your rules! The format is described in hosts.allow(5) and hosts.deny(5). Files used are usually /etc/hosts.allow and /etc/hosts.deny.

Login processes

The main purpose of login processes is to handle the IMAP, POP3, Submission (v2.3), and ManageSieve connections before the user has logged in. The login processes don't need to be able to do anything else than let the user log in, so they can run in highly restricted environment. By default they are run as a non-privileged "dovenull" user chrooted into a non-writable directory containing only authentication UNIX sockets.

Login processes also handle proxying the SSL and TLS connections even after the user has logged in. This way all the SSL code runs in the same restricted environment, which means that a security hole in the SSL library gives the attacker access only to the restricted chroot, rather than possibly all the users' mails.

The default login settings should be good enough for small sites. There are two ways to run the login processes: the high-security mode and the high-performance mode. Both are discussed separately below.

For explanation on the various settings for services, see Services

High-security mode

You can enable high-security mode with:

service imap-login {
  service_count = 1
  #process_min_avail = 0
  #process_limit = $default_process_limit
  #vsz_limit = 64M
}
service pop3-login {
  service_count = 1
}

This is the default. It works by using a new imap-login or pop3-login process for each incoming connection. Since the processes run in a highly restricted chroot, running each connection in a separate process means that in case there is a security hole in Dovecot's pre-authentication code or in the SSL library, the attacker can't see other users' connections and can't really do anything destructive. The only way out of it is to find and exploit a kernel security hole.

Since one login process can handle only one connection, the service's process_limit setting limits the number of users that can be logging in at the same time (defaults to default_process_limit=100). SSL/TLS proxying processes are also counted here, so if you're using SSL/TLS you'll need to make sure this count is higher than the maximum number of users that can be logged in simultaneously. With TLS/SSL connections, the login process will not terminate, and remains to perform proxying between imap backend process and the client.

  • If the maximum login process count is reached, the oldest process in logging-in state (ie. non-proxying) is destroyed.
  • To avoid startup latency for new client connections, set process_min_avail to higher than zero. That many idling processes are always kept around waiting for new connections.

  • vsz_limit should be fine at its default 64MB value.

High-performance mode

You can enable high-performance mode with:

service imap-login {
  service_count = 0
  #client_limit = $default_client_limit
  process_min_avail = 4 # number of CPU cores
  vsz_limit = 1G
}
service pop3-login {
  service_count = 0
}

It works by using a number of long running login processes, each handling a number of connections. This loses much of the security benefits of the login process design, because in case of a security hole (in Dovecot or SSL library) the attacker is now able to see other users logging in and steal their passwords, read their mails, etc.

  • process_min_avail should be set to be at least the number of CPU cores in the system, so that all of them will be used.

  • Otherwise new processes are created only once an existing one's connection count reaches client_limit
  • Default client_limit * process_limit = 1000*100 = 100k connections
  • vsz_limit should be increased to avoid out of memory errors, especially if you're using SSL/TLS.

Login access check sockets

Dovecot login processes can check via UNIX socket if the incoming connection should be allowed to log in. This is most importantly implemented to enable TCP wrappers support for Dovecot.

TCP wrappers support

You must have built Dovecot with support for TCP wrappers. You can do this by giving --with-libwrap parameter to configure.

Add to dovecot.conf:

login_access_sockets = tcpwrap

service tcpwrap {
  unix_listener login/tcpwrap {
    group = $default_login_user
    mode = 0600
    user = $default_login_user
  }
}

Remember to configure your rules! The format is described in hosts.allow(5) and hosts.deny(5). Files used are usually /etc/hosts.allow and /etc/hosts.deny.

None: LoginProcess (last edited 2019-03-21 07:18:09 by AkiTuomi)