Greetings, I am configuring a new Dovecot installation, and the way the valid_chroot_dirs and mail_chroot variables affect the mail processes are a bit unclear to me. I was wondering if anyone could provide me with more specific details than the comments in the configuration file do, or maybe even recommend some values given my configuration. We have a Debian GNU/Linux system and a mix of users with shell accounts and users with disabled logins. Both these groups should be handled the same way by Dovecot: auth_userdb is passwd and auth_passdb is pam. The dovecot PAM service will use pam_mysql.so, if that matters. Mail is in mbox format (we have too many sticklers who are set in their ways, unfortunately); I'm thinking default_mail_env should be mbox:~/Mail/:INBOX=/var/mail/%u. 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. So my best guess is that I should set the chroot variables like this: valid_chroot_dirs = /var/mail:/home mail_chroot = /var/mail I'm not sure about this though, for a number of reasons. Do I need to even chroot at all, or do I misunderstand the comments? 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? 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. Thanks in advance for any help you can offer, -- -- Brett Smith
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/mailThat 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>