Doveadm error since 2.3.11.3 when run as unprivileged user
I allow users to run 'doveadm' for mailbox maintenance (to expunge
mail for instance). Since the upgrade to 2.3.11.3, this no longer
works and results in the following error message:
doveconf: Fatal: Error in configuration file
/etc/dovecot/conf.d/10-ssl.conf line 13: ssl_key: Can't open file
/etc/ssl/private/de-korte.org.key: Permission denied
This is no surprise, as non-privileged users are not allowed to read
the private keys of the server. Question is, why is doveadm trying to
read this key in the first place (it is not needed for mailbox
maintenance) and why is it failing now?
Regards, Arjen
On 13. Aug 2020, at 11.00, Arjen de Korte build+dovecot@de-korte.org wrote:
I allow users to run 'doveadm' for mailbox maintenance (to expunge mail for instance). Since the upgrade to 2.3.11.3, this no longer works and results in the following error message:
doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 13: ssl_key: Can't open file /etc/ssl/private/de-korte.org.key: Permission denied
This is no surprise, as non-privileged users are not allowed to read the private keys of the server. Question is, why is doveadm trying to read this key in the first place (it is not needed for mailbox maintenance) and why is it failing now?
There were some ssl setting handling cleanups in v2.3.11, which caused this. I guess the proper fix for this would be to split SSL client settings and SSL server settings. So doveadm would still read the SSL client settings without trying to read the SSL server settings and failing there.
On 13. Aug 2020, at 11.29, Timo Sirainen timo@sirainen.com wrote:
On 13. Aug 2020, at 11.00, Arjen de Korte build+dovecot@de-korte.org wrote:
I allow users to run 'doveadm' for mailbox maintenance (to expunge mail for instance). Since the upgrade to 2.3.11.3, this no longer works and results in the following error message:
doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 13: ssl_key: Can't open file /etc/ssl/private/de-korte.org.key: Permission denied
This is no surprise, as non-privileged users are not allowed to read the private keys of the server. Question is, why is doveadm trying to read this key in the first place (it is not needed for mailbox maintenance) and why is it failing now?
There were some ssl setting handling cleanups in v2.3.11, which caused this. I guess the proper fix for this would be to split SSL client settings and SSL server settings. So doveadm would still read the SSL client settings without trying to read the SSL server settings and failing there.
As a workaround, it should be possible to put the ssl_key into a separate config file and use !Include_try for it. For example in dovecot.conf:
!include_try ssl-keys.conf
Citeren Timo Sirainen timo@sirainen.com:
On 13. Aug 2020, at 11.29, Timo Sirainen timo@sirainen.com wrote:
On 13. Aug 2020, at 11.00, Arjen de Korte
build+dovecot@de-korte.org wrote:I allow users to run 'doveadm' for mailbox maintenance (to expunge
mail for instance). Since the upgrade to 2.3.11.3, this no longer
works and results in the following error message:doveconf: Fatal: Error in configuration file
/etc/dovecot/conf.d/10-ssl.conf line 13: ssl_key: Can't open file
/etc/ssl/private/de-korte.org.key: Permission deniedThis is no surprise, as non-privileged users are not allowed to
read the private keys of the server. Question is, why is doveadm
trying to read this key in the first place (it is not needed for
mailbox maintenance) and why is it failing now?There were some ssl setting handling cleanups in v2.3.11, which
caused this. I guess the proper fix for this would be to split SSL
client settings and SSL server settings. So doveadm would still
read the SSL client settings without trying to read the SSL server
settings and failing there.As a workaround, it should be possible to put the ssl_key into a
separate config file and use !Include_try for it. For example in
dovecot.conf:!include_try ssl-keys.conf
That will only work to include an optional configuration file and
suppress errors if it doesn't exist. I put
ssl_key =
in a separate configuration file and it failed in a similar fashion,
just with another filename.
On Thu, Aug 13, 2020 at 21:16:42 +0200, Arjen de Korte wrote:
Citeren Timo Sirainen timo@sirainen.com:
!include_try ssl-keys.conf
That will only work to include an optional configuration file and
suppress errors if it doesn't exist. I putssl_key =
in a separate configuration file and it failed in a similar fashion,
just with another filename.
I think the idea was that the file with the ssl_key line was only root-readable. That way, non-privilged users will fail to include the file.
Is that what you tried?
Jeff.
-- I think there is a world market for maybe five computers. - Thomas Watson, chairman of IBM, 1943.
Citeren Josef 'Jeff' Sipek jeff.sipek@open-xchange.com:
On Thu, Aug 13, 2020 at 21:16:42 +0200, Arjen de Korte wrote:
Citeren Timo Sirainen timo@sirainen.com:
!include_try ssl-keys.conf
That will only work to include an optional configuration file and suppress errors if it doesn't exist. I put
ssl_key =
in a separate configuration file and it failed in a similar fashion, just with another filename.
I think the idea was that the file with the ssl_key line was only root-readable. That way, non-privilged users will fail to include the file.
Is that what you tried?
No, but you put me on the right track.
What is needed is to !include_try the whole previous SSL configuration
file only for root and to precede this by an include for a new one
which disables SSL completely. So first SSL will be disabled for all
users (including root) and only for root, the SSL configuration will
be loaded after that.
On Aug 13, 2020, Josef 'Jeff' Sipek jeff.sipek@open-xchange.com wrote:
On Thu, Aug 13, 2020 at 21:16:42 +0200, Arjen de Korte wrote:
Citeren Timo Sirainen timo@sirainen.com:
!include_try ssl-keys.conf
That will only work to include an optional configuration file and
suppress errors if it doesn't exist. I putssl_key =
in a separate configuration file and it failed in a similar fashion,
just with another filename.I think the idea was that the file with the ssl_key line was only root-readable. That way, non-privilged users will fail to include the file.
This worked for me. As mentioned, I had to make the new .conf file readable only by root.
Dan
participants (4)
-
Arjen de Korte
-
Dan Christensen
-
Josef 'Jeff' Sipek
-
Timo Sirainen