Make whitelist_modules only apply to remote dispatch - #69974
Merged
Conversation
twangboy
approved these changes
Aug 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #69983
What this changes
Splits the minion module loader into two views of the same set of modules:
with
whitelist_modules: [test, mycompany, saltutil]will refuse aremote publish of any module not in that list.
__salt__inside everyloaded module. So
mycompany.deploycan still do__salt__["cmd.run"](...)internally even when
cmdis off the whitelist.Combined with the existing per-command
cmd_blacklist_glob, this gives auseful defense-in-depth story for minions that don't fully trust the master:
[test, mycompany, saltutil, cmd]off → master can't publisharbitrary
cmd.runcallscmd_blacklist_glob: ["*rm -rf*"]→ even calls that reachcmd(throughinternal composition or if
cmdis later whitelisted) refuse specificdangerous strings
Adjacent fixes
salt/modules/saltcheck.py: moves the__context__["global_scheck"] = Noneinitialisation out of module-level code and into
__init__(opts)withsetdefault. The old pattern re-ran on everyexec_moduleand clobberedstate that a running function had already set — exposed by the two-loader
work above, but a pre-existing violation of the
__context__usage thedeveloping-modules docs prescribe (check-then-populate).
salt/utils/optsdict.py: caches the per-keyDictProxy/ListProxyinstead of allocating a new one on every read.
opts["grains"]drops from413 ns to 208 ns per read; no allocation churn on hot loops.
Tests
New:
tests/pytests/integration/loader/test_module_whitelist_dunder.py— 5tests covering direct-wire block, whitelisted-module reaches
non-whitelisted via
__salt__, and SLS render still respects whitelisttests/pytests/integration/renderers/test_renderer_whitelist.py— 2tests for the
renderer_whitelistsetting (defense in depth against#!pyin SLS)Broader-slice local run (
tests/pytests/unit/loader/,tests/pytests/functional/loader/,tests/pytests/integration/{loader,renderers,minion,states}/,tests/pytests/functional/modules/state/,tests/integration/modules/test_saltcheck.py):401 passed, 23 skipped, 1 unrelated env-permission failure
(
test_directory_recursecallschown -h nobodyas unprivileged user).Historical context
the cmd module, you can't disable it" — this PR removes that constraint
for the whitelist path.
whitelist_modules; thisPR delivers what that feature was supposed to do.
__context__semanticsgap; the saltcheck fix here aligns with the documented pattern but does
not attempt to close the broader persistence question.