Queried the two rows the handoff asked for. There is no `users` row for `officer_jg`, and
ids 2-4 are absent, which tells the whole story: an earlier row for jg@pertento.ai under the
`officer_`-prefixed naming got a Linux account at uid 1001, the row was deleted without
`userdel`, and the re-created account correctly refused to adopt it and took uid 1002. The
home is derived from the email, which never changed — hence two accounts, one home.
So this is the delete path, not a bypassed adoption rule, and it is observed rather than
theorised. Inert today: the home belongs to green and its ACL names only pastilhas and green,
so officer_jg cannot read it. The live hazard is uid 1001 going to the next member, which is
what deprovisionOsAccount and its chown to the service user would close.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Answers §1 of the per-user-accounts handoff and reviews the per-user-claude one.
A bind-mounted postgres:18-alpine starts, initialises and stays healthy under green's
rootless daemon — so 3bea46f's open question is closed. Two corrections though.
The mechanism in 401dcb7 is not the one doing the work. A container's inner uid never
traverses the host path: the daemon, running as the member who owns that path, resolves and
mounts it, and the container walks the result inside its own mount namespace. Measured here
with ~/.local/dockers at 770 — no x for other — and the container healthy anyway. What is
load-bearing is the DEFAULT-ACL removal, which is why directories created inside the bind
source come out 755. So the 711 is inert, and the file-browser access it costs is avoidable.
And the retrofit is incomplete: setfacl -R -b clears ACLs but not mode bits, so a member
whose ~/.local/dockers already holds data keeps 770 directories and stays broken. Green
cannot detect this — its data was recreated after the manual fix, so it reads as correct for
reasons that predate the commit.
On per-user-claude: NEVER_ENV cannot fire as written (it tests an allowlist-built object)
and is missing credential variables SDK 0.2.59 reads; memberClaudeBin is exported and never
used, so "their own binary" is enforced nowhere; the binary path is derived two different
ways; and env assignments ride in a world-readable argv.
VERIFIED: the mechanism, on this host, against a hand-applied fix.
NOT VERIFIED: 401dcb7's own provisioning path, which has never run here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pastilhasandClaude Opus 5