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.