dovecot - Apr 2008 - mail_chroot problems / dovecot 1.1rc4

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-file
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.

-------------- 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 ?).