Require consent before running project-supplied commands and host workers on the host#697
Merged
Merged
Conversation
…t workers on the host A project's committed .lerd.yaml is untrusted, yet several paths still ran its commands on the host with no consent: host:true workers from custom_workers and an embedded framework_def, and commands run via lerd run, the dashboard, and the commands_run MCP tool. An embedded framework_def is now stripped of its host workers and all commands when it is imported into the store, the same way the earlier fix stripped its command-type doctor checks, so the store never holds project-origin host execution. Project custom workers and commands are tagged at the merge points and gated at the host-execution boundary: a host custom worker and any project command show the exact command and ask once before running on the host, the approval is remembered per site so boot restore and later runs don't re-prompt, and a new host_commands.disabled / host_commands.skip_confirmation global mirrors the host-proxy knobs. Trusted store, built-in, and user-overlay definitions, in-container workers, and framework-provided commands are unaffected. Refs #692.
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
1 participant
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 the broad host-execution boundary that the #690/#691 fixes deliberately left open: a project's untrusted .lerd.yaml could still run commands on the host with no consent, through host:true workers (custom_workers and an embedded framework_def) and through commands run via lerd run, the dashboard, and the commands_run MCP tool.
An embedded framework_def is now stripped of its host:true workers and its whole commands list when it is imported into the store, the same way the doctor-command fix stripped its command checks, so the store never holds project-origin host execution. The host-proxy dev server keeps its own existing gate.
A project's own host extensions still work, with consent. Custom host workers and top-level project commands are tagged project-origin at the merge points and gated at the host-execution boundary: starting a host custom worker or running a project command shows the exact command and asks once, the approval is remembered per site (in the registry) so boot restore and later runs don't re-prompt, and lerd run --yes / the dashboard confirm modal / commands_run force: true carry that consent. A new host_commands.disabled and host_commands.skip_confirmation global mirror the host-proxy knobs. Trusted store, built-in, and user-overlay definitions, in-container workers, and framework-provided commands are unaffected.
A store yaml imported by an older build may still hold a poisoned framework_def host worker or command; detection rewrites the sanitized def on the next run, so it self-heals.
Refs #692