starred/modoboa-modoboa

Fork 0

mirror of https://github.com/modoboa/modoboa.git synced 2026-04-25 17:06:01 +03:00

[GH-ISSUE #2739] Calls to doveadm as part of custom PasswordHasher implementation spams auth log #1690

New issue

Closed

opened 2026-02-27 11:18:35 +03:00 by kerem · 3 comments

kerem commented

2026-02-27 11:18:35 +03:00

Owner

Originally created by @PatTheMav on GitHub (Jan 3, 2023).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/2739

Impacted versions

OS Type: Debian Linux
OS Version: Bullseye
Database Type: PostgreSQL
Database version: 13
Modoboa: 2.0.3
installer used: No
Webserver: Nginx

Steps to reproduce

Have modoboa corncobs configured and run
Observe entries in auth.log

Current behavior

The current model setup in Modoboa relies on a custom PasswordHasher implementation that uses doveadm pw -l to list all available password schemes in the local dovecot implementation.

From my observations this can lead to lots of unnecessary calls made during model initialisation, each of which results in a call to sudo and corresponding log entries, depending on the amount of users configured in the modoboa instance:

Biggest culprit seems to be the generate_rights command, which seems to initialise Models anew for each iteration of a loop, leading to pages of entries in auth.log just for a single invocation of the cron job.

While this issue can be alleviated somewhat by setting DOVECOT_SUPPORTED_SCHEMES in settings.py (which also allows "limiting" the schemes to only strong hashes), it makes the setup unresponsive to changes in the dovecot configuration (which seems like the original intent of the implementation).

Expected behavior

Ideally the results of the call should be cached, or maybe even retrieved in a separate cron job and stored in a config. While the configuration could change between calls to the user tables, the probability is comparatively low and the reduction of log spam would be appreciated.

Originally created by @PatTheMav on GitHub (Jan 3, 2023). Original GitHub issue: https://github.com/modoboa/modoboa/issues/2739 # Impacted versions * OS Type: Debian Linux * OS Version: Bullseye * Database Type: PostgreSQL * Database version: 13 * Modoboa: 2.0.3 * installer used: No * Webserver: Nginx # Steps to reproduce * Have modoboa corncobs configured and run * Observe entries in `auth.log` # Current behavior The current model setup in Modoboa relies on a custom `PasswordHasher` implementation that uses `doveadm pw -l` to list all available password schemes in the local `dovecot` implementation. From my observations this can lead to lots of unnecessary calls made during model initialisation, each of which results in a call to `sudo` and corresponding log entries, depending on the amount of users configured in the modoboa instance: Biggest culprit seems to be the `generate_rights` command, which seems to initialise Models anew for each iteration of a loop, leading to pages of entries in `auth.log` just for a single invocation of the cron job. While this issue can be alleviated somewhat by setting `DOVECOT_SUPPORTED_SCHEMES` in `settings.py` (which also allows "limiting" the schemes to only strong hashes), it makes the setup unresponsive to changes in the dovecot configuration (which seems like the original intent of the implementation). # Expected behavior Ideally the results of the call should be cached, or maybe even retrieved in a separate cron job and stored in a config. While the configuration _could_ change between calls to the user tables, the probability is comparatively low and the reduction of log spam would be appreciated.

kerem

2026-02-27 11:18:35 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-27 11:18:36 +03:00

Author

Owner

@MrGeneration commented on GitHub (Jan 11, 2023):

I have radicale related parts disabled on my instance. After upgrading to 2.0.3 however OPs described behavior appeared on my system as well but for opendkim.

opendkim umask 077 && $PYTHON $INSTANCE/manage.py modo manage_dkim_keys

Tries to call doveadm pw -l. Setting DOVECOT_SUPPORTED_SCHEMES did silence this behavior.
It may or may not have the same origin - personally I don't see why dkim key management should interact with dovecot at all.

Just leaving this here in case someone else has this issue and personally because I believe this might possibly even a bug.

@MrGeneration commented on GitHub (Jan 11, 2023): I have radicale related parts disabled on my instance. After upgrading to 2.0.3 however OPs described behavior appeared on my system as well but for opendkim. `opendkim umask 077 && $PYTHON $INSTANCE/manage.py modo manage_dkim_keys` Tries to call `doveadm pw -l`. Setting `DOVECOT_SUPPORTED_SCHEMES` did silence this behavior. It may or may not have the same origin - personally I don't see why dkim key management should interact with dovecot at all. Just leaving this here in case someone else has this issue and personally because I believe this might possibly even a bug.

kerem commented

2026-02-27 11:18:36 +03:00

Author

Owner

@PatTheMav commented on GitHub (Jan 11, 2023):

That's to be expected - the call to doveadm is implemented in a check for the application configuration class (where it's called in a list comprehension):

github.com/modoboa/modoboa@3714c002c9/modoboa/core/app_settings.py (L534)

So every time this object is created, doveadm will be called for every available password hashing algorithm because modoboa wants to ensure that only hashing algorithms also supported by the local dovecot instance are available in the Django admin settings.

Depending on how the cron job is implemented this settings object will be required and hence these calls will be made.

@PatTheMav commented on GitHub (Jan 11, 2023): That's to be expected - the call to `doveadm` is implemented in a check for the application configuration class (where it's called in a list comprehension): https://github.com/modoboa/modoboa/blob/3714c002c99f6aaa192a1a00eb607c71e05f190d/modoboa/core/app_settings.py#L534 So every time this object is created, `doveadm` will be called _for every available password hashing algorithm_ because modoboa wants to ensure that only hashing algorithms also supported by the local dovecot instance are available in the Django admin settings. Depending on how the cron job is implemented this settings object will be required and hence these calls will be made.

kerem commented

2026-02-27 11:18:36 +03:00

Author

Owner

@tonioo commented on GitHub (Jan 12, 2023):

@PatTheMav Good catch. Indeed, the current implementation does too many calls and we could easily lower it down. The setting was mainly added for cases where dovecot is not available on the same host than Modoboa... Caching the result is a good idea but it means it should be stored somewhere into the database.

@tonioo commented on GitHub (Jan 12, 2023): @PatTheMav Good catch. Indeed, the current implementation does too many calls and we could easily lower it down. The setting was mainly added for cases where dovecot is not available on the same host than Modoboa... Caching the result is a good idea but it means it should be stored somewhere into the database.

kerem referenced this issue

2026-02-27 12:10:15 +03:00

[PR #1690] [MERGED] Argon2 support #2283

kerem referenced this issue

2026-02-27 12:10:17 +03:00

[PR #1701] [MERGED] Make dependency on argon2 optional #2284