glas-harness/docs/evidence/GLAS-WP-0005-owner-boundary-2026-09-05.md
tegwick 63a7f9f160
Some checks failed
ci / validate (push) Has been cancelled
fix: execute local reins through the sandbox owner
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0726e-5232-73f2-aaca-2c05ceb62efb
2026-09-05 19:16:22 +02:00

68 lines
3.5 KiB
Markdown

# GLAS-WP-0005 sandbox owner boundary proof
Date: 2026-09-05. Sand-boxer revision:
`b6655d88590e03820675719d6dd574e5f5a9f82e`.
The Glas gateway now binds same-host execution to the creating manager's
`execute` operation. Each request repeats the exact actor/project identity and
resolved request id as `consumer.run_id`, forwards the selected profile's
value-free credential route references, and caps execution at the profile
timeout. Local descriptors without that process-local binding fail closed.
There is no direct `nsenter` or host task-file write path.
Generated task files travel through bounded stdin to an exclusive mode-0600
writer inside the sandbox's `.git` directory. Removal uses owner execution.
Timeouts, owner refusals, and truncated output fail closed; gateway teardown
still runs when session initialization fails.
## Live non-secret proof
Command: `.venv/bin/python scripts/prove-owner-boundary.py`.
This reproducible fixture exercises the real gateway, real sand-boxer manager,
real bwrap owner broker, and the rein-aharness adapter's session setup, commit
verification, and cleanup. Its dispatch is a deterministic Python/Git probe,
not an installed agent CLI or model call. Only the fixture's in-memory profile
is made unverified; the committed profile catalog is unchanged.
Successful sandbox: `e3907e55`, workspace `/tmp/sandboxer-bwrap/e3907e55`.
- Source checkout was absent inside the sandbox; a source write was refused.
- The sandbox copy was readable and accepted a new committed file.
- Host source sentinel and Git HEAD remained unchanged; no proof file appeared
in the source checkout.
- Actor `agt`, project `glas-boundary-proof`, and run id
`glas-wp-0005-boundary-proof` matched inside the child environment.
- Task content arrived through stdin and its file mode was `0600`.
- Only `lo` appeared in the network namespace.
- The generated task was removed before teardown. Final state was `destroyed`
and the workspace was absent.
An initial fixture run (`78be8886`) encountered a Python quoting error in the
probe itself. It failed during dispatch, removed its generated task, preserved
the source, and destroyed the workspace. The fixture quoting was corrected
before the successful run above.
## Validation and limits
`.venv/bin/python -m pytest tests/ -q`: **81 passed**. Coverage includes exact
create/exec identity with supplied and generated request ids, unchanged route
references, timeout caps, stdin-only task content, no local subprocess or host
file fallback, and teardown on owner refusal, timeout, truncation, and writer
failure. Both concrete adapters' session and cleanup tests pass.
`.venv/bin/glas-harness profiles`: catalog validation passed. Both local
profiles remain **blocked**; the remote profile remains **unverified**.
This closes the boundary-hardening acceptance in GLAS-WP-0005. It does not
prove an installed production rein runtime, credential delivery, required
outbound connectivity, or the remote SSH runtime. Registered residual
`GLAS-IN-0002` (`01a02b76-f020-7d60-a3ce-12a34c13ebce`) remains live for the
local production requirements and was refreshed before workplan closure.
Sand-boxer owns runtime/credential/egress provision; Glas owns the subsequent
real-rein acceptance and profile readiness review. The prior GLAS-WP-0004
lifecycle-only evidence remains explicitly withdrawn as an isolation proof.
Earlier T03 package and T04 Forgejo CI evidence remains historical; this
session validates the changed code locally and does not claim a new published
Forgejo run.