[Dovecot] [patch] make <chroot>/./<home> a config option.
Hi, I think that the wu-ftp style chroot /./ should be a configurable option.
In our servers we have some home directories in /chroot-web/./username (where web users can upload their web sites in a chrooted environment) and all imap mail in /mail-disk/username.
We are planning a dovecot migration from our modified version of uw-imap and we noticed that the chroot in /chroot-web/ can't be disabled.
This patch adds the bool option home_slash_dot_slash_chroot (feel free to change this name to something easier to understand). Setting this to "no" disables the wu-ftp style /./ chroot.
I hope this feature can be considered useful and soon included in dovecot.
Regards, Diego Liziero.
On Fri, 2008-02-15 at 13:40 +0100, Diego Liziero wrote:
This patch adds the bool option home_slash_dot_slash_chroot (feel free to change this name to something easier to understand). Setting this to "no" disables the wu-ftp style /./ chroot.
There are already too many options, but I guess valid_chroot_dirs could be used for this. Committed to v1.1: http://hg.dovecot.org/dovecot-1.1/rev/17c65dfdac2a
On Fri, 2008-02-15 at 14:53 +0200, Timo Sirainen wrote:
On Fri, 2008-02-15 at 13:40 +0100, Diego Liziero wrote:
This patch adds the bool option home_slash_dot_slash_chroot (feel free to change this name to something easier to understand). Setting this to "no" disables the wu-ftp style /./ chroot.
There are already too many options, but I guess valid_chroot_dirs could be used for this. Committed to v1.1: http://hg.dovecot.org/dovecot-1.1/rev/17c65dfdac2a
Great, but this patch solves partially what we would like to have: it allows chroot options to be completely disabled, but it doesn't allow to override /./ chroot with a global mail_chroot option.
This happens because to have mail_chroot config option working, we have to add its entry in valid_chroot_dirs, too. This should not be necessary.
In this case validate_chroot should be called before checking for mail_chroot (see the patch below).
Thank you for your quick answer, Regards, Diego Liziero.
Diego,
I tried to send this direct, but apparently your helo/header checks are way too aggressive:
<<< 550 5.7.1
Nuvox is our ISP, and they are big in the commercial sector here in the states...
On 2/16/2008, Diego Liziero (diego.liziero@comune.carpi.mo.it) wrote:
In this case validate_chroot should be called before checking for mail_chroot (see the patch below).
Maybe you missed it...
Timo's patch is only against 1.1, NOT 1.0.x...
It didn't sound like he was interested in changing this for 1.0.x...
--
Best regards,
Charles
On Sat, 2008-02-16 at 13:44 +0100, Diego Liziero wrote:
There are already too many options, but I guess valid_chroot_dirs could be used for this. Committed to v1.1: http://hg.dovecot.org/dovecot-1.1/rev/17c65dfdac2a
Great, but this patch solves partially what we would like to have: it allows chroot options to be completely disabled, but it doesn't allow to override /./ chroot with a global mail_chroot option.
This happens because to have mail_chroot config option working, we have to add its entry in valid_chroot_dirs, too. This should not be necessary.
Hmm. I guess it shouldn't. http://hg.dovecot.org/dovecot-1.1/rev/1f982f1201ef http://hg.dovecot.org/dovecot-1.1/rev/de96d58b6ee2
participants (3)
-
Charles Marcus
-
Diego Liziero
-
Timo Sirainen