doveadm/doveconf as user tries and fails to read host key
Distro: OpenSuSE Tumbleweed for x86_64 Failing version: dovecot23-2.3.11.3-1.1.x86_64 Install Date: 2020-08-18 Reverting to previous version works: dovecot23-2.3.10.1-2.3.x86_64 (Packages downgraded coordinately: dovecot23 dovecot23-backend-sqlite)
How to make it fail: As the user, execute doveadm expunge mailbox Spam37 savedbefore 3day #User's actual cmd doveadm who #The simplest possible command, for testing It says: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 12: ssl_cert: Can't open file /etc/ssl/hostcerts/hostw.cia: Permission denied
The actual EPERM occurs trying to traverse a directory in /etc/letsencrypt, but the next configuration item to be read (in the SSL section) is the host's private key, and the user is surely not ever going to get permission to read that. (I did test giving the user permission to the 750 directory and it did attempt to read the private key, failing.) If you run it as root, of course it works because root has read permission. The initial failure was seen running as the user from cron.
Behavior seen in strace: doveadm execs doveconf; doveconf reads the configuration and saves it somewhere (shared memory?); doveconf execs the next program which in this case is doveadm with its original command line; and doveadm now knows its configuration. I can re-do and post the strace if needed.
I don't know why doveconf is reading the SSL keys in 2.3.11.3 when it didn't in 2.3.10.1, but if the idea is to read the complete configuration in case it might be needed in obscure situations, a possible workaround is to not die on unreadable secrets and to report those either as unset or as a new "error" symbol, letting the consumer (doveadm) deal with the fallout, or in this case ignore it.
Attached: sysreport.gz ; doveconf-n.out Dovecot's working files and user mailboxes are on ext4 filesystems; NFS is not involved. The mail reader is Roundcube webmail.
-- James F. Carter Email: jimc@jfcarter.net Web: http://www.math.ucla.edu/~jimc (q.v. for PGP key)
Citeren jimc jimc@jfcarter.net:
Distro: OpenSuSE Tumbleweed for x86_64 Failing version: dovecot23-2.3.11.3-1.1.x86_64 Install Date: 2020-08-18 Reverting to previous version works: dovecot23-2.3.10.1-2.3.x86_64 (Packages downgraded coordinately: dovecot23 dovecot23-backend-sqlite)
How to make it fail: As the user, execute doveadm expunge mailbox Spam37 savedbefore 3day #User's actual cmd doveadm who #The simplest possible command, for testing It says: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 12: ssl_cert: Can't open file /etc/ssl/hostcerts/hostw.cia: Permission denied
This was mentioned before on this list. See
https://dovecot.org/pipermail/dovecot/2020-August/119650.html how to
solve this.
The actual EPERM occurs trying to traverse a directory in /etc/letsencrypt, but the next configuration item to be read (in the SSL section) is the host's private key, and the user is surely not ever going to get permission to read that. (I did test giving the user permission to the 750 directory and it did attempt to read the private key, failing.) If you run it as root, of course it works because root has read permission. The initial failure was seen running as the user from cron.
Behavior seen in strace: doveadm execs doveconf; doveconf reads the configuration and saves it somewhere (shared memory?); doveconf execs the next program which in this case is doveadm with its original command line; and doveadm now knows its configuration. I can re-do and post the strace if needed.
I don't know why doveconf is reading the SSL keys in 2.3.11.3 when it didn't in 2.3.10.1, but if the idea is to read the complete configuration in case it might be needed in obscure situations, a possible workaround is to not die on unreadable secrets and to report those either as unset or as a new "error" symbol, letting the consumer (doveadm) deal with the fallout, or in this case ignore it.
Attached: sysreport.gz ; doveconf-n.out Dovecot's working files and user mailboxes are on ext4 filesystems; NFS is not involved. The mail reader is Roundcube webmail.
On 2020-08-23 21:59, Arjen de Korte wrote:
Citeren jimc jimc@jfcarter.net:
Failing version: dovecot23-2.3.11.3-1.1.x86_64 Install Date: 2020-08-18 -snip-
This was mentioned before on this list. See https://dovecot.org/pipermail/dovecot/2020-August/119650.html how to solve this.
@Arjen, thanks for the quick and useful reply. I implemented it and it works. For explicitness here's what I did: In /etc/dovecot/conf.d I put these 3 files, most comments redacted:
10-ssl.conf: # Everyone gets the dummy config that turns off SSL !include 10-ssl.all # Only root can read this file (and the host key it mentions) (mode 600) !include_try 10-ssl.root
10-ssl.all: ssl = no
10-ssl.root: (owned by root, mode 600) ssl = yes ssl_key =
For testing:
- Upgraded to dovecot23-2.3.11.3-1.1.x86_64 and friends, and restarted dovecot.
- doveadm expunge mailbox Spam37 savedbefore 3day As user: works. strace shows doveconf silently skips 10-ssl.root, getting EACCESS.
- doveadm who My bad -- this command doesn't call doveconf, testing nothing.
- sleep 1 | openssl s_client -connect jacinth.jfcarter.net:143 -starttls imap --or-- sleep 1 | openssl s_client -connect jacinth.jfcarter.net:993 Verify return code: 0 (ok) and TLS session ticket was granted for both. Be careful to use the ports and hostname (IP) that the firewall is expecting.
- Normal use from Roundcube: connects and gets/deletes mail normally. TLS is required for this.
-- James F. Carter Email: jimc@jfcarter.net Web: http://www.math.ucla.edu/~jimc (q.v. for PGP key)
participants (2)
-
Arjen de Korte
-
jimc