doveadm expunge unnecessarily tries to access TLS key
I have just upgraded my Debian Buster (Dovecot 2.3.4, I think it was) to Bullseye (Dovecot 2.3.13).
The Dovecot server works fine, which of course is the really important thing.
But I have a cron job that cleans up all old mail from the mailbox that I use for my mobile phone by running "doveadm expunge" every night.
That worked fine in 2.3.4, but now it fails:
jdmobile@nuser:~$ doveadm expunge mailbox '*' before 25d doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 23: ssl_cert: Can't open file /etc/letsencrypt/live/nuser.dybdal.dk/fullchain.pem: Permission denied
Of course, doveadm cannot access the TLS key when running as a normal user. But why should it try to access that key at all when I have just asked it to clean up my own files in my own Maildir? Is there a way to make it not try to access that key and do its job anyway? Or another way to delete old mail?
(I could give it a "-u jdmobile" option and run it as root - but I really like to run things like that as a non-privileged user, so I won't make a stupid mistake that destroys the wrong mailbox.)
Thanks, Jesper
-- Jesper Dybdal https://www.dybdal.dk
On 27/03/2023 16:42 EEST Jesper Dybdal <jd-dovecot@dybdal.dk> wrote:
I have just upgraded my Debian Buster (Dovecot 2.3.4, I think it was) to Bullseye (Dovecot 2.3.13).
The Dovecot server works fine, which of course is the really important thing.
But I have a cron job that cleans up all old mail from the mailbox that I use for my mobile phone by running "doveadm expunge" every night.
That worked fine in 2.3.4, but now it fails:
jdmobile@nuser:~$ doveadm expunge mailbox '*' before 25d doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 23: ssl_cert: Can't open file /etc/letsencrypt/live/nuser.dybdal.dk/fullchain.pem: Permission denied
Of course, doveadm cannot access the TLS key when running as a normal user. But why should it try to access that key at all when I have just asked it to clean up my own files in my own Maildir? Is there a way to make it not try to access that key and do its job anyway? Or another way to delete old mail?
(I could give it a "-u jdmobile" option and run it as root - but I really like to run things like that as a non-privileged user, so I won't make a stupid mistake that destroys the wrong mailbox.)
Thanks, Jesper
-- Jesper Dybdal https://www.dybdal.dk
Hi!
This is a known issue, to work around it, use
ssl=no !include_try conf.d/ssl.conf
and put ssl=yes in ssl.conf along with your cert & key. then chmod it 0600.
This is also fixed in 2.3.20.
Aki
On 2023-03-27 16:31, Aki Tuomi wrote:
On 27/03/2023 16:42 EEST Jesper Dybdal <jd-dovecot@dybdal.dk> wrote:
I have just upgraded my Debian Buster (Dovecot 2.3.4, I think it was) to Bullseye (Dovecot 2.3.13).
The Dovecot server works fine, which of course is the really important thing.
But I have a cron job that cleans up all old mail from the mailbox that I use for my mobile phone by running "doveadm expunge" every night.
That worked fine in 2.3.4, but now it fails:
jdmobile@nuser:~$ doveadm expunge mailbox '*' before 25d doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 23: ssl_cert: Can't open file /etc/letsencrypt/live/nuser.dybdal.dk/fullchain.pem: Permission denied Of course, doveadm cannot access the TLS key when running as a normal user. But why should it try to access that key at all when I have just asked it to clean up my own files in my own Maildir? Is there a way to make it not try to access that key and do its job anyway? Or another way to delete old mail?
(I could give it a "-u jdmobile" option and run it as root - but I really like to run things like that as a non-privileged user, so I won't make a stupid mistake that destroys the wrong mailbox.)
Thanks, Jesper
-- Jesper Dybdal https://www.dybdal.dk Hi!
This is a known issue, to work around it, use
ssl=no !include_try conf.d/ssl.conf
and put ssl=yes in ssl.conf along with your cert & key. then chmod it 0600.
This is also fixed in 2.3.20.
Thank you very much! The workaround seems to work just fine.
Jesper
--
Jesper Dybdal https://www.dybdal.dk
participants (2)
-
Aki Tuomi
-
Jesper Dybdal