discussion about "Remove doveadm_allowed_commands setting"
Hi Timo, hi list,
I saw this commit (https://github.com/dovecot/core/commit/2b0947986ccb72e2f5ce13f8bd4b300e94e38...) on Dovecot's github repo:
doveadm: Remove doveadm_allowed_commands setting The setting only compared the first command name against a list, which gave a false sense of security. Anyone who is allowed to connect to the doveadm server can already do practically anything with the commands that were typically allowed: most commands take a -u/-A user parameter, and commands like sync, backup and import take parameters that access arbitrary paths. Restricting the command name doesn't change that, so doveadm access must be given only to trusted clients regardless.
I tried to understand the detailed reasoning but I don't get it. As far as I can follow the code not only the *first command name* is checked but every command send (in the list of commands via HTTP API).
From our point of view, this setting has a clear security benefit like this:
security: we only allow specific doveadm commands via doveadm-server and some more when coming from localhost
doveadm_allowed_commands = user,who local 127.0.0.1/8 { doveadm_allowed_commands = user,who,"sieve list","sieve get","sieve put","sieve activate" }
It limits the allowed commands in general to who and user which are read-only. Only if the connection is comming from localhost, we additionally grant some sieve commands for our web interface to manage and test sieve rulesets (https://gitlab.mpi-klsb.mpg.de/pcernko/sieveweb). All other commands are not allowed at all, e.g. it is not possible to delete mails or use dsync via the HTTP API. This policy matches our general security policy to only grant what's needed.
So, Timo, I would like to ask, why this setting has to get removed (I assume in the next release) or if it can be restored again in the main branch?
Is there anyone else using this setting besides me? What do the other users think about the removal of the setting?
Best regards,
Patrick Cernko <pcernko@mpi-klsb.mpg.de> +49 681 9325 5815 Joint Scientific IT and Technical Service Max-Planck-Institute für Informatik & Softwaresysteme
On 3. Sep 2026, at 10.14, Patrick Cernko via dovecot <dovecot@dovecot.org> wrote:
From our point of view, this setting has a clear security benefit like this:
security: we only allow specific doveadm commands via doveadm-server and some more when coming from localhost
doveadm_allowed_commands = user,who local 127.0.0.1/8 { doveadm_allowed_commands = user,who,"sieve list","sieve get","sieve put","sieve activate" }
It limits the allowed commands in general to who and user which are read-only. Only if the connection is comming from localhost, we additionally grant some sieve commands for our web interface to manage and test sieve rulesets (https://gitlab.mpi-klsb.mpg.de/pcernko/sieveweb). All other commands are not allowed at all, e.g. it is not possible to delete mails or use dsync via the HTTP API. This policy matches our general security policy to only grant what's needed.
So, Timo, I would like to ask, why this setting has to get removed (I assume in the next release) or if it can be restored again in the main branch?
Having this setting is bad, because it can provide false sense of security. It's not at all obvious which commands are safe and which aren't. Using your list as an example: The doveadm user command already is risky because it supports -e parameter, which supports %variable expansion. If mail_lua plugin is loaded, you can run a function in a Lua script that exists somewhere on the filesystem. In the future it's possible that we add a %function that allows directly executing some commands or reading some files on the system. Also, you can already use %{env:x} to look at environment variables, which may contain secrets in some installations.
There are also commands that already allow arbitrary code execution via -p parameter: doveadm sync, backup, import.
If you need actual security would be better to have some proxy in the middle, which sends only safe commands with safe parameters towards doveadm.
participants (2)
-
Patrick Cernko
-
Timo Sirainen