[Dovecot] 1.0rc29: LDA chroot problem
Hi,
I got strange problem with dovecot LDA;
in dovecont.conf: mail_chroot = /srv/vmail
deliver(test@fakedomain.net): Apr 03 07:28:21 Info: auth input: test@fakedomain.net deliver(test@fakedomain.net): Apr 03 07:28:21 Info: auth input: uid=400 deliver(test@fakedomain.net): Apr 03 07:28:21 Info: auth input: gid=400 deliver(test@fakedomain.net): Apr 03 07:28:21 Info: auth input: home=/fakedomain.net/test deliver(test@fakedomain.net): Apr 03 07:28:21 Info: auth input: mail=maildir:/fakedomain.net/test deliver(test@fakedomain.net): Apr 03 07:28:21 Fatal: chroot(/srv/vmail) failed: Operation not permitted
error appears even after "chmod 777 /srv/vmail". imap works without problems.
Uldis
On Tue, 2007-04-03 at 03:35 +0300, Uldis Pakuls wrote:
Hi,
I got strange problem with dovecot LDA;
in dovecont.conf: mail_chroot = /srv/vmail
deliver(test@fakedomain.net): Apr 03 07:28:21 Info: auth input: test@fakedomain.net deliver(test@fakedomain.net): Apr 03 07:28:21 Info: auth input: uid=400 deliver(test@fakedomain.net): Apr 03 07:28:21 Info: auth input: gid=400 deliver(test@fakedomain.net): Apr 03 07:28:21 Info: auth input: home=/fakedomain.net/test deliver(test@fakedomain.net): Apr 03 07:28:21 Info: auth input: mail=maildir:/fakedomain.net/test deliver(test@fakedomain.net): Apr 03 07:28:21 Fatal: chroot(/srv/vmail) failed: Operation not permitted
You don't start deliver as root (or setuid root), so it can't do the chrooting.
Usually MTAs don't allow starting deliver as root, so your only possibilities are setuid root (see the wiki page) or not using chrooting with deliver.
Timo Sirainen wrote:
You don't start deliver as root (or setuid root), so it can't do the chrooting.
Usually MTAs don't allow starting deliver as root, so your only possibilities are setuid root (see the wiki page) or not using chrooting with deliver. setuid works, but another problem arise: when chrooted, deliver can't find plugins e.g "Fatal: opendir (/usr/lib/dovedot/modules/lda) failed: no such file or directory"
is there any way to fix it?
Uldis
On Tue, 2007-04-03 at 08:17 +0300, Uldis Pakuls wrote:
setuid works, but another problem arise: when chrooted, deliver can't find plugins e.g "Fatal: opendir (/usr/lib/dovedot/modules/lda) failed: no such file or directory"
Fixed: http://dovecot.org/list/dovecot-cvs/2007-April/008561.html
Timo Sirainen wrote:
On Tue, 2007-04-03 at 08:17 +0300, Uldis Pakuls wrote:
setuid works, but another problem arise: when chrooted, deliver can't find plugins e.g "Fatal: opendir (/usr/lib/dovedot/modules/lda) failed: no such file or directory"
Fixed: http://dovecot.org/list/dovecot-cvs/2007-April/008561.html
now deliver works, but... problems with plugins - at least with sieve plugin: deliver(test@fakedomain.net): Apr 03 12:03:06 Info: cmusieve: Using sieve path: /fakedomain.net/test/.dovecot.sieve deliver(test@fakedomain.net): Apr 03 12:03:06 Info: msgid=46124272.99Vnol6ezL7EdMyt%root@fakedomain.net: saved mail to INBOX deliver(test@fakedomain.net): Apr 03 12:03:06 Fatal: execv(/usr/lib/sendmail) failed: No such file or directory deliver(test@fakedomain.net): Apr 03 12:03:06 Error: Sendmail process terminated abnormally, exit status 75
**sieve plugin tries to forward mail... and fails when chroot enabled.
Uldis
On Tue, 2007-04-03 at 15:10 +0300, Uldis Pakuls wrote:
deliver(test@fakedomain.net): Apr 03 12:03:06 Fatal: execv(/usr/lib/sendmail) failed: No such file or directory .. **sieve plugin tries to forward mail... and fails when chroot enabled.
Put the sendmail binary inside chroot and change sendmail_path setting. Although I don't know if even that will work. It might want to write directly to the mail spool instead of connecting to the SMTP server via TCP.
The other possibility is to disable chrooting with deliver.
On 3.4.2007, at 16.20, Uldis Pakuls wrote:
Timo Sirainen wrote:
The other possibility is to disable chrooting with deliver. Is it possible to disable chrooting for deliver only? What about maildir/box paths then?
What userdb do you use? There's no simple "disable chrooting"
setting, but if you have good enough userdb you could return non-
chrooted settings to deliver. With SQL and checkpassword this should
be easy. With others it might be possible to kludge it. Anyway the
idea is to check if %s expands to deliver or something else.
Timo Sirainen wrote:
**sieve plugin tries to forward mail... and fails when chroot enabled. Put the sendmail binary inside chroot and change sendmail_path setting. Although I don't know if even that will work. It might want to write directly to the mail spool instead of connecting to the SMTP server via TCP.
This means i must set up real chroot environment for sendmail... ldd shows up a lots of dependencies.
The other possibility is to disable chrooting with deliver.
While deliver itself uses external binaries too - is it a good idea to chroot deliver process at all?
participants (2)
-
Timo Sirainen
-
Uldis Pakuls