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


Traditionally chrooting has been done to run the whole server within a single chroot. This is also possible with Dovecot, but it requires manually setting up the chroot and it can be a bit tricky. Dovecot however supports internally running different parts of it in different chroots:

Security problems

If chrooting is used incorrectly, it allows local users to gain root privileges. This is possible by hardlinking setuid binaries inside the chroot jail and tricking them. There are at least two possibilities:

  1. Hardlink /bin/su inside the chroot and create your own <chroot>/etc/passwd. Then simply run su root.

  2. Create your own <chroot>/lib/ and run any setuid binary.

Of course both of these require that the setuid binary can be run inside the chroot. This isn't possible by default. Either user would have to find a security hole from Dovecot, or the administrator would have had to set up something special that allows running binaries.

In any case it's a good idea not to allow users to hardlink setuid binaries inside the chroots. The safest way to do this is to mount the filesystem with "nosuid" option.

Mail process chrooting

Due to the potential security problem described above, Dovecot won't chroot mail processes to directories which aren't listed in valid_chroot_dirs setting. For example if your users may be chrooting under /var/mail/<user>/ and /home/<user>/, use:

valid_chroot_dirs = /var/mail:/home

You can chroot all users globally into the same directory by using mail_chroot setting. For example:

mail_chroot = /home

You can also make userdb return a chroot. There are two ways to do that:

  1. Make userdb return chroot=<path> field.

  2. Insert "/./" inside the returned home directory, eg.: home=/home/./user to chroot into /home, or home=/home/user/./ to chroot into /home/user.

Chrooting (last edited 2009-03-15 22:35:09 by localhost)