fix: close the '*'-only flood_scopes bypass and schedule write race

A flood_scopes of "*" alone leaves scope_keys empty while setting
flood_scope_allow_global, and the loader already logs that as an active
allowlist. The handler gated on scope_keys alone, so that configuration
skipped authorisation entirely and admitted absent, uncorrelated and
TRANSPORT_FLOOD traffic. The gate now fires when either is set, so "*"
means global-only rather than everything.

The scheduled-message duplicate check ran outside the write lock inside
update_ini_values, so two concurrent creates for the same schedule could
both pass and the second silently replace the first instead of getting
the 409. Check and write are now one critical section, and delete is too.
Repaired the delete path's error handling while moving it, so an OSError
during the write is still a 500 rather than escaping.
This commit is contained in:
agessaman committed 2026-08-22 01:06:08 -07:00
1 parent 088097734b
commit bf70594b41
3 files changed
+68 -12

No files matched your search

+5 -2
View File
@@ -2398,8 +2398,11 @@ class MessageHandler:
# Allowlist enforcement: when flood_scopes is configured, only reply to
# messages whose scope matched an entry. Unscoped FLOOD is allowed only
# when '*' (or equivalent) is explicitly listed.
if scope_keys and reply_scope is None:
allow_global = getattr(cmd_mgr, "flood_scope_allow_global", False)
allow_global = getattr(cmd_mgr, "flood_scope_allow_global", False)
# A '*'-only flood_scopes leaves scope_keys empty but still means an
# allowlist is configured (global only). Gating on scope_keys alone let
# that configuration skip authorisation entirely.
if (scope_keys or allow_global) and reply_scope is None:
if (
scope_rf_data
and scope_rf_is_correlated