coilyco-flight-deck/ward

Archived

Watch

Make ward exec resolve the canonical Make entry on Linux #1538

Closed

opened 2026-07-24 07:49:43 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-07-24 07:49:43 +00:00

Owner

Outcome

Make ward exec honor a declared bare system entry such as make after PATH resolution and canonicalization on Linux.

When a repository verb declares run: make ... and policy authorizes that entry, resolving make to a canonical system path such as /usr/bin/make must not fail merely because the executable is outside the repository.

Required behavior

Resolve the declared bare entry through the execution environment's PATH.
Canonicalize the resolved executable before launch.
Apply the existing command and sandbox policy to the declared entry and canonical executable without treating an external system path as an automatic denial.
Preserve rejection for undeclared, unresolved, substituted, or policy-denied executables.
Make ward doctor report actionable errors for entries that cannot be resolved or authorized.

Acceptance criteria

A disposable Linux fixture declares a bare make, resolves it to a canonical system executable outside the repository, and reaches the configured child command.
Canonicalization does not broaden the allowed command beyond the declared entry.
Missing, substituted, and policy-denied entries fail before execution with actionable diagnostics.
Existing executable identity and sandbox boundaries remain enforced.
Repository validation passes.

Headless execution boundary

Use a temporary PATH, synthetic executable, and disposable repository fixture. Do not run the original infrastructure command, invoke Ansible, or mutate a live host for acceptance.

## Outcome Make `ward exec` honor a declared bare system entry such as `make` after PATH resolution and canonicalization on Linux. When a repository verb declares `run: make ...` and policy authorizes that entry, resolving `make` to a canonical system path such as `/usr/bin/make` must not fail merely because the executable is outside the repository. ## Required behavior * Resolve the declared bare entry through the execution environment's PATH. * Canonicalize the resolved executable before launch. * Apply the existing command and sandbox policy to the declared entry and canonical executable without treating an external system path as an automatic denial. * Preserve rejection for undeclared, unresolved, substituted, or policy-denied executables. * Make `ward doctor` report actionable errors for entries that cannot be resolved or authorized. ## Acceptance criteria * A disposable Linux fixture declares a bare `make`, resolves it to a canonical system executable outside the repository, and reaches the configured child command. * Canonicalization does not broaden the allowed command beyond the declared entry. * Missing, substituted, and policy-denied entries fail before execution with actionable diagnostics. * Existing executable identity and sandbox boundaries remain enforced. * Repository validation passes. ## Headless execution boundary Use a temporary PATH, synthetic executable, and disposable repository fixture. Do not run the original infrastructure command, invoke Ansible, or mutate a live host for acceptance.

coilyco-ops added the

autonomy

async-consult

priority

labels

2026-07-29 03:47:17 +00:00

coilyco-ops added

and removed

labels

2026-07-31 08:29:35 +00:00

coilyco-ops added

priority

and removed

priority

labels

2026-08-05 10:26:08 +00:00

coilyco-ops commented

2026-08-05 18:17:21 +00:00

Author

Owner

Design decision settled on 2026-08-05.

Close this issue as stale because the core behavior already ships:

Ward passes the executable declared in .ward/ward.yaml directly to cli-guard.
cli-guard resolves bare names through PATH before execution.
The Linux jail resolves symlinks, stashes the real executable, and launches that exact target.
Existing engine coverage exercises a synthetic external PATH tool through the Linux jail.
Ward has no rule that denies an executable merely because it is outside the repository.
The requested ward doctor addition targets a retired adoption surface.

No implementation or replacement issue is needed. If a concrete make failure recurs, file the observed command, environment, and error as a new reproducible defect.

Design decision settled on 2026-08-05. Close this issue as stale because the core behavior already ships: * Ward passes the executable declared in .ward/ward.yaml directly to cli-guard. * cli-guard resolves bare names through PATH before execution. * The Linux jail resolves symlinks, stashes the real executable, and launches that exact target. * Existing engine coverage exercises a synthetic external PATH tool through the Linux jail. * Ward has no rule that denies an executable merely because it is outside the repository. * The requested ward doctor addition targets a retired adoption surface. No implementation or replacement issue is needed. If a concrete make failure recurs, file the observed command, environment, and error as a new reproducible defect.

coilyco-ops closed this issue

2026-08-05 18:17:22 +00:00

Commenting is not possible because the repository is archived.

No milestone

No project

No assignees

1 participant

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/ward#1538

No description provided.

Rows
Columns