Why would "doveadm mailbox" check certificate file access?
The following came as a nasty surprise while testing Dovecot 2.4.1-4:
alice@host $ doveadm mailbox list -u $(whoami) doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf line 61: cert_file: open(/path/to/cert.pem) failed: Permission denied
Unprivileged user Alice does not have access to cert.pem, nor does she need it. Calling "doveadm flags ..." causes the same error. I suspect other subcommands are affected as well, but did not test it.
The technical reason might be that dovecot.conf is parsed for each doveadm invocation? In any case, the certificate access check for subcommands like "flags" or "mailbox" seems like a bug to me.
-Ralph
I have the same issue since the 2.4 update, in my case affecting use of dovecot-lda as a transport for Postfix.
The transport invokes dovecot-lda as an unprivileged user 'vmail' and it fails with the same permission error showing up in syslog.
Immediate remedial options of loosening permissions on private key file(s) or invoking dovecot-lda as root are suboptimal to say the least (the latter would probably break my virtual mailbox config anyway).
The technical reason might be that dovecot.conf is parsed for each doveadm invocation?
This is borne out by the manpage: "All standalone programs, such as dovecot(1), will first get their settings by executing doveconf, unless they can get the settings by connecting to the config UNIX socket."
This may or may not be applicable with doveadm depending upon your personal config and what subcommands are needed, but for dovecot-lda I think a solution that may work is to create a separate config file, minus the ssl_* directives, to use instead of the normal dovecot.conf in this context.
In any case, the certificate access check for subcommands like "flags" or "mailbox" seems like a bug to me.
Agreed, because it in effect makes these commands only runnable by root (unless you want to live with sloppy file permissions on your SSL keys).
Doveconf needs to be more context-aware and/or be permitted to not puke on the certs being unreadable in certain invocations. It's probably a lot more complex to address for doveadm due to its scope (when I use it I usually have needed to be root anyway) but lda has no use for SSL whatsoever as far as I'm aware so it should be able to invoke doveconf without configs that don't concern it causing errors.
Best, Robin
On 15/06/2025 19:24 EEST dovecot-ml--- via dovecot <dovecot@dovecot.org> wrote:
I have the same issue since the 2.4 update, in my case affecting use of dovecot-lda as a transport for Postfix.
The transport invokes dovecot-lda as an unprivileged user 'vmail' and it fails with the same permission error showing up in syslog.
Immediate remedial options of loosening permissions on private key file(s) or invoking dovecot-lda as root are suboptimal to say the least (the latter would probably break my virtual mailbox config anyway).
The technical reason might be that dovecot.conf is parsed for each doveadm invocation?
This is borne out by the manpage: "All standalone programs, such as dovecot(1), will first get their settings by executing doveconf, unless they can get the settings by connecting to the config UNIX socket."
This may or may not be applicable with doveadm depending upon your personal config and what subcommands are needed, but for dovecot-lda I think a solution that may work is to create a separate config file, minus the ssl_* directives, to use instead of the normal dovecot.conf in this context.
In any case, the certificate access check for subcommands like "flags" or "mailbox" seems like a bug to me.
Agreed, because it in effect makes these commands only runnable by root (unless you want to live with sloppy file permissions on your SSL keys).
Doveconf needs to be more context-aware and/or be permitted to not puke on the certs being unreadable in certain invocations. It's probably a lot more complex to address for doveadm due to its scope (when I use it I usually have needed to be root anyway) but lda has no use for SSL whatsoever as far as I'm aware so it should be able to invoke doveconf without configs that don't concern it causing errors.
Best, Robin
you can also try creating /etc/dovecot/conf.d/ssl.conf and put the ssl config there, then have !include_try /etc/dovecot/conf.d/*.conf and chmod 0600 ssl.conf? This should help workaround this issue.
Aki
Thanks, that works well for my situation.
I fear it'll be far less clear-cut for doveadm though. (But probably it was always true that some subcommands would work and some not depending on invoking user's privilege, and there weren't guardrails against such issues, is that right?)
Best, Robin
participants (3)
-
Aki Tuomi
-
dovecot-ml＠headbank.co.uk
-
Ralph Seichter