doveadm requires read access to SSL key
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dovecot (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Released
|
Undecided
|
Bryce Harrington |
Bug Description
[Impact]
When running doveadm on a dovecot configured to use SSL, if the user doesn't have read permissions for ssl_cert or ssl_key, doveadm will fail with a fatal error and non-zero exit code. This impacts cronjobs and tools like Postfixadmin, as is being widely reported in the wild.
[Test Plan]
* Prepare the LXC container:
$ sudo apt-get update
$ sudo apt-get -y full-upgrade
* Do a dovecot configuration with SSL certificates, where the SSL key is
only readable by the root user. These restrictive permissions on the
SSL key should work per the dovecot configuration, as the server reads
the files before dropping its privileges.
https:/
"Dovecot opens both of these files while still running as root, so you
don’t need to give Dovecot any special permissions to read them (in
fact: do not give dovecot user any permissions to the key file)."
https:/
Generate a custom certificate using openssh:
$ sudo openssl req -new -x509 -days 1000 -nodes -out "/etc/dovecot/
-keyout "/etc/dovecot/
* Set the SSL settings by editing /etc/dovecot/
make sure the cert and key config looks like this:
ssl_cert = </etc/dovecot/
ssl_key = </etc/dovecot/
$ sudo systemctl stop dovecot.service
$ sudo systemctl start dovecot.service
* Run doveadm as root, it should output the help text.
$ sudo doveadm
usage: doveadm [-Dv] [-f <formatter>] <command> [<args>]
altmove [-u <user>|-A] [-S <socket_path>] [-r] <search query>
...
* Run doveadm as another user, e.g. the one set for mail_uid in the
dovecot configuration (for me, this is the user vmail) - doveadm will
not show the help text but die with an error like:
$ doveadm
doveconf: Fatal: Error in configuration file /etc/dovecot/
That error will be gone if you apply the above commits to the 2.3.16
source (tried that). Whether there are any regressions I cannot tell
though.
Due to the quantity of lines changed and the types of changes being made, that it would be worth longer than usual testing in -proposed before rolling out to all users.
User testing in production can be of value, since the principle impact is the side effects from hitting the fatal error, rather than the error itself.
[Where Problems Could Occur]
The fix itself is straightforward, but it builds on several other refactoring patches. Since that's a large number of lines affected it's infeasible to visually ascertain the correctness of the changes. While in theory these could be re-implemented to minimize the number of code lines changed, doing so would introduce some unknown level of risk of adding errors via typos or other mistakes. For that reason, the new proposed package carries the set of patches unmodified from upstream.
The refactoring changes include changes to internal APIs (i.e. new and changed functions and structs) and behavioral changes when SSL is enabled. Dovecot is a service rather than a library, so the API changes shouldn't affect other software shipped in Ubuntu, however there exists the potential that there may be internal callers to the changed APIs that were missed in the refactoring.
Due to the patches changing behavior with SSL, it would be also worth watching for odd behavioral effects when enabling SSL, and issues related to configuration.
[Original Report]
Since upgrading from focal to jammy, I have issues with my cronjobs running doveadm as the vmail user (e.g., to train bayes filter). doveadm dies as it tries to read the SSL private key, although it does not need it.
This is a known bug in dovecot that was fixed with 2.3.17. I believe this is critical since granting the vmail user read permissions to the private SSL key is not desirable from a security perspective.
The corresponding entry in the Dovecot 2.3.17 changelog:
doveadm: v2.3.11 regression: Commands failed if ssl_cert or ssl_key files weren't readable by the user running doveadm, even though doveadm didn't actually use these settings
Answers to the requested information:
Description: Ubuntu 22.04.1 LTS
Release: 22.04
dovecot-core:
Installed: 1:2.3.16+
Candidate: 1:2.3.16+
Version table:
*** 1:2.3.16+
500 http://
500 http://
100 /var/lib/
1:
500 http://
Related branches
- git-ubuntu bot: Approve
- Athos Ribeiro (community): Approve
- Canonical Server Reporter: Pending requested
- Canonical Server Core Reviewers: Pending requested
- Canonical Server: Pending requested
-
Diff: 1095 lines (+1049/-0)7 files modifieddebian/changelog (+12/-0)
debian/patches/remove-unnecessary-master_service_flag_use_ssl_settings.patch (+112/-0)
debian/patches/remove-unused-master_service_is_ssl_module_loaded.patch (+62/-0)
debian/patches/series (+5/-0)
debian/patches/split-master_service_ssl_settings_to_iostream_set-to-client-server-functions.patch (+258/-0)
debian/patches/split-off-master_service_ssl_server_settings.patch (+473/-0)
debian/patches/use-ssl-server-settings-only-when-necessary.patch (+127/-0)
Changed in dovecot (Ubuntu Jammy): | |
assignee: | nobody → Bryce Harrington (bryce) |
Changed in dovecot (Ubuntu Jammy): | |
importance: | Undecided → High |
tags: | removed: server-todo |
tags: | added: server-todo |
Changed in dovecot (Ubuntu Jammy): | |
status: | Incomplete → New |
Changed in dovecot (Ubuntu Jammy): | |
status: | New → Triaged |
description: | updated |
description: | updated |
Changed in dovecot (Ubuntu Jammy): | |
status: | Triaged → Fix Committed |
Changed in dovecot (Ubuntu Jammy): | |
status: | Fix Committed → In Progress |
tags: |
added: verification-done removed: verification-needed |
tags: |
added: verification-done verification-done-jammy removed: verification-needed verification-needed-jammy |
Thanks for taking the time to report this bug and trying to make Ubuntu better.
This was indeed fixed in version 2.3.17 per upstream NEWS file:
https:/ /github. com/dovecot/ core/blob/ 2.3.17/ NEWS#L40- L42
However, going through the commits I was not able to easily spot the needed commit(s) to be backported to Jammy. I am adding this bug to our backlog.