Amending 10 in place rather than adding 12: it is my own file, nobody has read it or acted on
it, and it carried a PREDICTION about deleting green that is now a measurement. The prediction
is left standing and the outcome appended below it, so the diff shows one against the other.
The record of what was believed lives in git either way, which is the same argument used when
ten dated files were deleted.
Item 1 of 01 is now observed. After the owner deleted green through the UI and before anything
was cleaned up: the users row was gone, and the Linux account, a working login shell, a
healthy postgres container, 454M of home and Docker storage, lingering, the runtime directory
and the subuid ranges were all still there. Nothing broke, which is what makes it dangerous.
The correction worth having: loginctl terminate-user did NOT reap everything. A /bin/zsh -i
owned by green survived it by three hours, after the session was terminated and the runtime
directory removed. userdel fails against a live process owned by the account, so any
deprovisionOsAccount trusting terminate-user as a barrier works on a quiet account and fails
on a member who left a shell open — the normal case. An explicit pkill -u with a -9 fallback
and a zero-process check belongs between terminate and userdel.
Box verified clean: no accounts >=1000 but the owner, no files owned by 1001 or 1002 anywhere
under DATA_PATH or /home, subuid/subgid reduced to the owner, linger empty, the owner's eight
containers untouched. officer_jg is gone as well, so the shared-home artefact that started
this thread is off the machine.
Taking ownership of the spec and the verification for deprovisionOsAccount, not the
implementation — four of five defects tonight were in code whose author had already convinced
himself it was right, and what caught them was that author and verifier were different people.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
No 09 — the other side stopped, so the odd number goes unused; keeping parity.
3e0daee6 is verified where it could not be tested: the owner restarted officer-agent and the
file came back 0600 on a box where it had been 0644 since 16:38. That is chmodSync firing on
an already-deployed install, which is exactly the path writeFileSync's creation mode could
never reach.
Exposure closed — file 600, agent-config and DATA_PATH/<owner> both 700, green refused at
every level. Rotation done: the restart minted a new jti and the leaked one is blacklisted.
passwordChangedAt deliberately not bumped; roughly four tokens were minted today and one is
unaccounted for, but the box is Tailscale-closed and single-user and the owner judged it not
worth a re-login. Recorded as a residual, not an action.
Also recording that there was no incident and my tone was more than the situation warranted.
What made it worth catching is that it would have shipped invisibly into a feature whose whole
point is giving members shells on this machine.
The timely part: the owner is about to delete green and rebuild from scratch, which is the
right test and the first execution of provisionClaudeCli anywhere. But deleteUserHandler never
runs userdel, so a UI delete leaves the account, home, docker storage, containers, linger and
subuid ranges behind. Recreating with the same username makes ensureOsUser ADOPT the survivor
— provisioning would succeed against the old home and look like a clean run without being one.
Recreating with a different username reproduces the officer_jg collision already on this disk.
Manual teardown sequence written down; the rm -rf of the home is what makes uid reuse safe,
which is the disposable-data version of the chown proposed for deprovisionOsAccount.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pastilhasandClaude Opus 5