Admins can now supply managed policy helpers as an inline script instead of a file on disk.
What's wrong with this entry?
The admin-controlled policyHelpers config, which computes managed settings at startup, now accepts a script plus interpreter pair as an alternative to path. The script is handed to the interpreter over stdin and never written to disk. It is capped at 65536 characters, must be NUL-free valid UTF-8, and must be ASCII-only on Windows. The interpreter is fixed per operating system: sh on macOS, Linux and WSL, pwsh on Windows.
- Validation now requires each entry to carry
path, orscript+interpreter, and/ordefaultSettings(a static settings payload); mixingpathwithscriptis rejected. - Inline scripts only work on the per-OS
policyHelpersmap. On the older singularpolicyHelperkey they are refused with "inline scripts are not supported on the singular policyHelper key". - Execution is
/bin/sh -sover stdin, or pwsh with-Commandwrapping the script in a fixed fragment endingcatch { Write-Error $_; exit 1 }; exit $LASTEXITCODE. - No feature flag guards the parser; it is reachable for anyone whose admin-controlled policy settings carry such an entry. None of this vocabulary existed in v2.1.233.
Inline helper script, delivered to the fixed interpreter over stdin (never written to disk), inline scripts are not supported on the singular policyHelper key
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.228
Managed settings accept per-OS
policyHelpersBoth mention policy helper managed
-
v2.1.228
New
policyHelpersmanaged-settings key for per-OS policy helper executablesBoth mention policy helper managed
-
v2.1.232
Warnings when policy helper settings are nested in the wrong place
Both mention policy helper managed