Why does doveadm always run doveconf?
Dear fellow Dovecot users,
I've recently been aiding in the fixing up of the old dovecot_stats_ munin plugin. Currently, it still parses the output of doveadm oldstats, as it is quite an old script. Regardless of any feelings we may all have about oldstats, I was quite surprised to find that doveadm requires quite broad privileges (in my case root privileges) to function properly. It seems that any call to doveadm, even for "doveadm oldstats dump domain" runs doveconf and will attempt to fully parse my configuration including trying to read SSL/TLS certificates. Due to this choice, the fact the FIFO of oldstats can be given low privileges, doveadm still has to be invoked with high privileges or it will fail at the stage of verifying configuration.
Now I'm wondering why it's the case that a command such as "doveadm oldstats dump domain" is invoking doveconf and therefore has these kinds of limitations. While for basically all non-stats functions of doveadm, running as root (or similar) makes a lot of sense, I'd argue it doesn't for oldstats (and maybe also the new stats?), which simply talk to a socket. Is there a certain reasoning behind this, or is this accidental behaviour because of the standard operations doveadm always performs? Any elaboration would be more than welcome!
Kind regards, Bert
On 18/01/2023 22:01, Bert Van de Poel wrote:
I was quite surprised to find that doveadm requires quite broad privileges (in my case root privileges) to function properly.
This is, I think, a "feature" that was introduced in 2.3. It can make life difficult. There's a message somewhere on the mailing list describing this, but I can't currently find it. The OP wanted his users to be able to set up something, but found that they couldn't.
Thanks for your reply and the follow-up link that came afterwards. From https://dovecot.org/pipermail/dovecot/2020-August/119644.html I do get the impression that this behaviour is undesired and that it's actually a Dovecot bug to confound client and server SSL settings. I'm however not sure if the person who remarks that is actually just stating his opinion or the view of the project. However, the term "workaround" does further imply that this situation is not as intended. I would normally file a bug in a bug tracker for this (so it can at least be discussed and easily found), but it seems Dovecot doesn't have one. Is that correct?
I had hoped I had found a cleaner workaround (that could even become a default suggestion) by moving ssl_cert and ssl_key into "protocol imap {}" but it seems that even that gets evaluated when running doveadm. Is the situation literally that doveadm is parsing all configuration even if it's irrelevant for its use?
The version of Dovecot I'm running, 2.3.13, dates from well after when this error was reported in August 2020. This has me concerned that this bug is an "accepted defect", "intended behaviour" or has just been lost in discussion and due to the lack of a bug tracker. So I'm not quite sure how to continue from here. I could of course use the "!include_try" hack, but that can't be the suggested method, and if it is, it should be explicitly mentioned in the documentation and config examples in my opinion.
On 19/01/2023 11:50, EML wrote:
On 18/01/2023 22:01, Bert Van de Poel wrote:
I was quite surprised to find that doveadm requires quite broad privileges (in my case root privileges) to function properly.
This is, I think, a "feature" that was introduced in 2.3. It can make life difficult. There's a message somewhere on the mailing list describing this, but I can't currently find it. The OP wanted his users to be able to set up something, but found that they couldn't.
participants (2)
-
Bert Van de Poel
-
EML