admin
e59e3c0ae2
Full validation of the felhom pool + scoped-token migration on felhom-pve: - Track A: complete agent op surface under the scoped token — 16/16 pass - Track B: vmid origin traced (externally supplied); adversarial collision probes prove the compensating rollback/teardown attempts to destroy a guest the job never created (contained only by the pool ACL) - Track C: containment + 3b-fix intact; Track D: no pool leaks, adopt/ uninstall pool handling correct - Findings doc: documentation/audits/CAMPAIGN-pool-effects-2026-07-01.md No code change, no version bump. Demo left as found. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
3.3 KiB
felhom.eu — task reports
Overwrite this file with a summary of the most recent task only (uniform with the other repos; not cumulative). The cumulative hub history lives in hub/CHANGELOG.md; the scripts history lives in scripts/CHANGELOG.md.
REPORT — "no-mercy" campaign: full effects of the felhom pool + scoped-token migration
Date: 2026-07-02 · Class: Runbook-style validation (aggressive, throwaway env) · No code change, no version bump.
Findings doc: documentation/audits/CAMPAIGN-pool-effects-2026-07-01.md
Executed the full pool-effects campaign on felhom-pve (agent v0.59.0 live, host-install v1.7.0 scoped ACL): source-traced every ListLXC consumer in felhom-agent (read-only), then ran the complete agent→PVE operation matrix under the scoped token on scratch pool guests 9310/9311, adversarial pool-blindness probes with non-pool decoys, blast-radius regression re-confirms, and pool-membership side-effect checks.
Headline results
- Track A — 16/16 ops PASS, zero surprise 403s. The scoped token is functionally complete for the agent's real operation surface (incl. the previously untested Destroy+disk-reap, Snapshot/Rollback/Delete, SetConfig Network/CPU/Options, Resize, ListRunningTasks, TaskLogTail, and the full restore-test cycle).
- B1 (the campaign's most important result): the provision vmid is always externally supplied (no
nextidscan in agent OR hub — collision-avoidance is operator-side). Adversarially provisioning onto an existing non-pool vmid: the pool-blind duplicate guard misses it, PVE refuses the restore (no clobber), but the compensating rollback then attempts to DESTROY the innocent guest — stopped only by the pool ACL (403). Same shape live-proven for the restore-test scratch band (a squatter at 990000 additionally makes the restore-test permanently FAIL with false "backup unrestorable" alerts). Safe-but-noisy under the scoped ACL; a genuine destroy-risk under any broad token. - Containment intact (Track C): non-pool guest ops 403, non-granted-storage writes 403, drive audit readable (3b-fix holds).
- Hub inventory is pool-only (B3, by design — now recorded as a decision): operators must pick vmids from the host's real guest list, never the hub view. No pool-name leak into any customer/controller-facing field (Track D);
--adopt-poolidempotent; uninstall never deletes a non-empty pool.
Fix list (full detail + severities in the findings doc)
- F1 (HIGH, blocks shared-box trial): arm the bring-up/restore-test compensating destroy only after
RestoreLXCreturns a UPID — never destroy what the job didn't create. - F2 (MED, blocks trial): restore-test should advance past an "already exists" band vmid (or pre-verify via fenced root CLI); document 990000–990009 as reserved fleet-wide.
- F3 (MED, doc-only, blocks trial): provisioning runbook must say vmid selection uses the host's full guest list, not the hub inventory.
- F4/F5/F6 (LOW/INFO): non-pool source-config read in restore-test, pool-blind eject dependent-scan, latent reconcile desired-state rule.
Demo left exactly as found: pool felhom = {9201}, all scratch/decoy guests and campaign artifacts removed, agent active, controller healthy.