[Dovecot] Questions about mail process chroots

[Timo Sirainen]

On 22.9.2004, at 05:21, Brett Smith wrote:

> So, if I understand correctly, (a) I should set chroots on the mail
> processes, since some of our users don't have real shell accounts, and 
> (b)
> those processes will need access to /var/mail and home directories 
> under
> /home.

There's no need to do chrooting for users who don't have shell 
accounts. Dovecot shows only files under the defined mail directory.

> So my best guess is that I should set the chroot variables like this:
>
> valid_chroot_dirs = /var/mail:/home
> mail_chroot = /var/mail

That wouldn't work. If you chroot to /var/mail, there's no way to 
access /home directory. And vice versa.

> Do I need to even chroot at all, or do I misunderstand the comments?

What comments suggest using it? I thought it only warns against using 
it :)

> If I do need to chroot, the comments about valid_chroot_dirs warn very
> strongly that the chroot dirs should not be writeable by users.  /home
> itself isn't writeable by users, but obviously their home directories 
> are.
> Is listing /home also vulnerable to exploits?  If it is, what would a 
> good
> solution be?

The problem comes if user is able to hardlink setuid-root binaries into 
home directory and then find some way to make Dovecot execute them. It 
shouldn't be possible, but imap code is complex and there could be 
bugs. Perhaps in future it's also possible to allow user-made plugins 
and chrooting is definitely a bad idea then.

> What's the meaning of /./ in mail_chroot?  The comments about it,
> unfortunately, make no sense at all to me.  It says that /home/./user 
> is
> the same as /home, but if that's completely true, why wouldn't I just 
> say
> mail_chroot = /home?  I even looked into the source and it still wasn't
> really clear to me.

It meant that in user database you can override the mail_chroot setting 
by adding /./ in the home directory. So for example you could set 
different chroots for different users. I'll clarify the comment.
-------------- 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/20040922/0bd29fa5/attachment-0001.bin>