I'd like to see tcp-wrappers.patch getting integrated into dovecot.
I ported the original 1.0 patch to 1.1, but would prefer not to have to maintain
another local patch.
As the name suggests, the patch adds libwrap support to dovecot. We use is to
limit access from outside our network to secure (imaps/pop3s) protocols only and
to exclude certain internal addresses from accessing dovecot in general.
I fully understand Timo's concern of people not reading documentation and
then whining that librwapping doesn't work whereas they simply forgot to put
hosts.{allow,deny} into the login chroot.
Would it be acceptable if either dovecot itself or the init script copies
/etc/hosts.{allow,deny} into the chroot (unless it's already there)?
Also, dovecot could probably complain/abort/turn off libwrap if these files are
missing in the login chroot.
The problem mainly occurs with the default (Linux) setting of login_dir =
/var/run/dovecot/login; on NetBSD, I use /var/chroot/dovecot-login instead,
which doesn't get wiped out at boot.
Comments? Suggestions?
Oh, yes, managesieve (which uses src/login-common) would need a slight update,
too.
On Wed, 23 Jul 2008 15:31:20 +0200 Edgar Fu? wrote:> I'd like to see tcp-wrappers.patch getting integrated into dovecot. > I ported the original 1.0 patch to 1.1, but would prefer not to have to maintain another local patch. > > As the name suggests, the patch adds libwrap support to dovecot. We use is to limit access from outside our network to secure (imaps/pop3s) protocols only and to exclude certain internal addresses from accessing dovecot in general.Why this? I do this with iptables. --Frank Elsner
On Jul 23, 2008, at 9:31 AM, Edgar Fu? wrote:> I fully understand Timo's concern of people not reading > documentation and then whining that librwapping doesn't work whereas > they simply forgot to put hosts.{allow,deny} into the login chroot.Or they modify it in /etc and wonder why Dovecot doesn't see the changes.> Would it be acceptable if either dovecot itself or the init script > copies /etc/hosts.{allow,deny} into the chroot (unless it's already > there)?Then it would also have to keep checking when they change and copy.. Another kind of a problem is that it just makes the master process more complex again. I'd like this to wait until v2.0's master process rewrite. Then there could be a separate non-chrooted process that does tcpwrapper checks and perhaps some other checks. -------------- 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/20080804/cd5ff745/attachment-0002.bin>