dovecot - Aug 2020 - 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 at jfcarter.net
Web: http://www.math.ucla.edu/~jimc (q.v. for PGP key)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sysreport.gz
Type: application/gzip
Size: 2832 bytes
Desc: not available
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20200823/b46705ae/attachment.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doveconf-n.out
Type: text/x-c++
Size: 1737 bytes
Desc: not available
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20200823/b46705ae/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20200823/b46705ae/attachment.sig>

Citeren jimc <jimc at 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 at 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 = </etc/ssl/private/hostw.key
# etc. etc.  This is the original SSL configuration.

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 at jfcarter.net
Web: http://www.math.ucla.edu/~jimc (q.v. for PGP key)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20200824/775c11ba/attachment.sig>