disable_modules is a documented, promoted config option that has no effect

[dwoz]

Problem

disable_modules is documented as a way to prevent specific execution
modules from loading on a minion. It appears in:

• doc/topics/hardening.rst:78 — literally suggests disable_modules: [cmd]
  as a hardening measure
• doc/ref/configuration/minion.rst:1845 — full documentation with a YAML
  example
• doc/topics/development/modules/configuration.rst:10 — cross-referenced
  from developer docs

The setting is declared in salt/config/__init__.py:334 (schema) and
initialised to [] at line 1275. No code anywhere in salt/ reads it.
Grep the tree — only the schema declaration and default appear; no consumer.

Consequence

disable_modules accepts any value, prints no warning, and does nothing.
Users following the hardening docs believe they have disabled a module when
they haven't.

Reproduction

# /etc/salt/minion
disable_modules:
  - cmd

Restart minion.

salt '*' cmd.run 'id'
# still returns normally — cmd is loaded and callable

History

• Disabling CMD module on minion #25854 (2015) — user reported disable_modules: cmd didn't work; in
  comments they discovered disable_modules: cmdmod (the filename, not the
  virtualname) did — but that variant then broke the minion because
  internals require cmd.
• Disabling cmd module causes connection error to master #52592 (2019) — same pain, closed with publisher_acl_blacklist as
  workaround.

At some point between then and now, whatever enforcement code existed was
removed. The docs weren't updated.

Fix options

Pick one:

1. Restore the feature. Make the loader honour disable_modules again.
   Note: this reintroduces the "many parts of salt use cmd" problem that
   killed the original implementation. Combining it with whitelist_modules on the minion blocks internal module composition, forcing all-or-nothing security #69983 (which
   expands whitelist_modules to only apply to the wire) would give a
   coherent story: disable_modules blocks from the wire only, internals
   keep working.
2. Officially deprecate. Remove the setting from docs, emit a warning
   if it appears in config, and drop it in a future release. Direct users
   to whitelist_modules (once whitelist_modules on the minion blocks internal module composition, forcing all-or-nothing security #69983 lands) plus master-side
   publisher_acl_blacklist.

Related: #69983, PR #69974.

[dwoz]

Filed under a wrong premise: the setting is read at salt/loader/lazy.py:364 and enforced at :676 against file basenames, so disable_modules: [cmdmod] does work today. The gap is only that the virtual-name form ([cmd]) shown in the hardening docs isn't matched. Closing; will re-file more accurately.