Hello I've noticed a little strange behaviour of that option. For example with following settings: system user: admin, with its home directory as /home/admin dovecot options: as reported by dovecot -n (in attachment) dovecot will try to chroot into /home/home/admin with the following message in logs, in my case: Fatal: chdir(/home/home/admin) failed with uid 1999: No such file or directory The same happens if I use per-user chroot= option in userdb, f.e. in passwd-file I've noticed it's just now, as I've always used explicit chroot dirs specified through passwd-file with /./ (which works perfectly fine, except harmless double slashes in logs), and didn't bother with single system user (I made some chroot/lock related bugreports in distant 1.0rcXX past). Cheers Michal -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dovecot.conf URL: <http://dovecot.org/pipermail/dovecot/attachments/20080403/7cbcad9f/attachment-0002.pl>
On Apr 3, 2008, at 11:33 AM, Michal Soltys wrote:> dovecot will try to chroot into /home/home/admin with the following > message in logs, in my case: > > Fatal: chdir(/home/home/admin) failed with uid 1999: No such file or > directory > > The same happens if I use per-user chroot= option in userdb, f.e. in > passwd-fileRight. If you use mail_chroot or chroot, the home directory points under the chroot. I guess it might be also useful for it not to do that, but I can't change that without breaking backwards compatibility, and I'm not sure if it's worth it to add yet another setting just for that. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20080404/f81ee878/attachment-0002.bin>
Timo Sirainen wrote:> > Right. If you use mail_chroot or chroot, the home directory points under > the chroot. I guess it might be also useful for it not to do that, but I > can't change that without breaking backwards compatibility, and I'm not > sure if it's worth it to add yet another setting just for that. >So in such case - is there any way to chroot mail processes for userdb that can't (or shouldn't) use /./ and can't modify HOME to fit mail_chroot setting ? Like system's passwd, or other where changing HOME would/could break other things ? I know what you mean by breaking backwards compatibility in this context, but in this way, mail_chroot is practically unusable besides custom-userdb + dovecot-only setups. And in this scenario - you can simply use /./ (point being, in a way - is there anyone actually using mail_chroot / chroot along with stripped HOME paths ?).