[Dovecot] 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
# 1.1.rc4: /etc/dovecot.conf base_dir: /var/dovecot/ protocols: imap imaps pop3 pop3s ssl_listen: * ssl_ca_file: /etc/ssl/cert_bundle.pem ssl_cert_file: /etc/ssl/ca_ppgk/certs/fetch_crt.pem ssl_key_file: /etc/ssl/ca_ppgk/private/fetch_key.pem verbose_ssl: yes login_dir: /var/dovecot/login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(pop3): /usr/local/libexec/dovecot/pop3-login login_greeting: Dovecot IMAP server ready. login_greeting_capability(default): yes login_greeting_capability(imap): yes login_greeting_capability(pop3): no login_process_size: 32 valid_chroot_dirs: /home mail_chroot: /home verbose_proctitle: yes first_valid_uid: 1999 first_valid_gid: 10 mail_location: maildir:~/mspace/maildir:INDEX=~/mspace/index:INBOX=~/mspace/inbox:CONTROL=~/mspace/control mail_debug: yes fsync_disable: yes lock_method: flock mbox_read_locks: flock mbox_write_locks: flock mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(pop3): /usr/local/libexec/dovecot/pop3 mail_plugins(default): quota imap_quota mail_plugins(imap): quota imap_quota mail_plugins(pop3): quota mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 imap_client_workarounds(default): outlook-idle delay-newmail tb-extra-mailbox-sep imap_client_workarounds(imap): outlook-idle delay-newmail tb-extra-mailbox-sep imap_client_workarounds(pop3): pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh namespace: type: private separator: / inbox: yes list: yes subscriptions: yes auth default: mechanisms: plain login verbose: yes debug: yes passdb: driver: passwd-file args: /etc/dovecot.z1.passwd passdb: driver: passwd-file args: /etc/dovecot.passwd passdb: driver: passwd userdb: driver: passwd-file args: /etc/dovecot.z1.passwd userdb: driver: passwd-file args: /etc/dovecot.passwd userdb: driver: passwd socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix plugin: quota: maildir
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.
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 ?).
On Apr 4, 2008, at 4:02 PM, Michal Soltys wrote:
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 ?).
Could you try if this works: http://hg.dovecot.org/dovecot-1.1/rev/9edaf878bb96
Timo Sirainen wrote:
On Apr 4, 2008, at 4:02 PM, Michal Soltys wrote:
Could you try if this works: http://hg.dovecot.org/dovecot-1.1/rev/9edaf878bb96
Both global and per-user chroot settings work fine with that patch.
Thanks !
participants (2)
-
Michal Soltys
-
Timo Sirainen