container: /etc/ward-git-credentials provisioned 0600 root:root, unreadable by the non-root agent (blocks push, leaks attribution) #288

New issue

Closed

opened 2026-06-24 17:14:14 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-06-24 17:14:14 +00:00

Member

Surfaced by the headless agent carrying #282 (see its closing retro comment).

Symptom

Inside the agent container, /etc/ward-git-credentials was provisioned 0600 root:root instead of the intended 0640 root:<agent-gid>. The agent runs non-root, so it could not read the git credential helper file, and the final git push to Forgejo main failed on credentials.

Workaround used (not a fix)

The run fell back to the entrypoint's documented FORGEJO_TOKEN env via a tiny Go GIT_ASKPASS helper (the pre-commit hook rightly blocks shell-script helpers and token expansion in commands, so a Go shim was the clean path). The push then succeeded.

Side effect worth noting

Because the push authed via FORGEJO_TOKEN (Kai's token) rather than the coilyco-ops bot credential the credential file would have carried, the merge commit and the retro comment on #282 are attributed to coilysiren, not coilyco-ops. So this perm bug also causes an agent-attribution leak onto Kai's identity.

Fix

In the container provisioning that writes /etc/ward-git-credentials (entrypoint / bootstrap), set mode 0640 and group-own it by the agent's gid so the non-root agent can read it, and confirm the bot credential (not the human FORGEJO_TOKEN) is what lands there. Add a provisioning assertion (or a doctor probe) that the file is agent-readable before the run starts, so a future regression fails loudly instead of silently falling back to the human token.

Scope

Container-provisioning bug, not specific to that issue's work - every non-root agent run hits the same file. Likely in the container entrypoint/bootstrap that materializes git credentials.

Surfaced by the headless agent carrying https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/282 (see its closing retro comment). ## Symptom Inside the agent container, `/etc/ward-git-credentials` was provisioned **`0600 root:root`** instead of the intended **`0640 root:<agent-gid>`**. The agent runs non-root, so it could not read the git credential helper file, and the final `git push` to Forgejo main failed on credentials. ## Workaround used (not a fix) The run fell back to the entrypoint's documented `FORGEJO_TOKEN` env via a tiny Go `GIT_ASKPASS` helper (the pre-commit hook rightly blocks shell-script helpers and token expansion in commands, so a Go shim was the clean path). The push then succeeded. ## Side effect worth noting Because the push authed via `FORGEJO_TOKEN` (Kai's token) rather than the `coilyco-ops` bot credential the credential file would have carried, the merge commit and the retro comment on https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/282 are attributed to `coilysiren`, not `coilyco-ops`. So this perm bug also causes an agent-attribution leak onto Kai's identity. ## Fix In the container provisioning that writes `/etc/ward-git-credentials` (entrypoint / bootstrap), set mode `0640` and group-own it by the agent's gid so the non-root agent can read it, and confirm the bot credential (not the human `FORGEJO_TOKEN`) is what lands there. Add a provisioning assertion (or a doctor probe) that the file is agent-readable before the run starts, so a future regression fails loudly instead of silently falling back to the human token. ## Scope Container-provisioning bug, not specific to that issue's work - every non-root agent run hits the same file. Likely in the container entrypoint/bootstrap that materializes git credentials.

coilyco-ops added the

interactive

labels

2026-06-24 17:20:19 +00:00

coilysiren referenced this issue from a commit

2026-06-24 17:27:21 +00:00

fix(container): re-assert git cred perms before agent drop (ward#288)

coilysiren closed this issue

2026-06-24 17:27:21 +00:00

coilyco-ops commented

2026-06-24 17:30:43 +00:00

Author

Member

Re-triage (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24)

P1 - Diagnosed cred-perm bug: file lands 0600 root:root, non-root agent cannot read it, push fails and falls back to FORGEJO_TOKEN. Blocks headless push and leaks Kai's attribution onto agent commits. Concrete fix, near-term.
interactive - Touches container provisioning + the credential path and needs an end-to-end push verify that the bot cred lands, not the human token. Agent works it then a human confirms attribution.

**Re-triage** (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24) - **P1** - Diagnosed cred-perm bug: file lands 0600 root:root, non-root agent cannot read it, push fails and falls back to FORGEJO_TOKEN. Blocks headless push and leaks Kai's attribution onto agent commits. Concrete fix, near-term. - **interactive** - Touches container provisioning + the credential path and needs an end-to-end push verify that the bot cred lands, not the human token. Agent works it then a human confirms attribution.

coilyco-ops referenced this issue

2026-06-24 17:58:59 +00:00

headless --repo: a secondary-repo push can silently fail while the run closes the issue as done #291