Write prewarm secret files under the data root, not Dir.tmpdir

[JPDuchesne]

On macOS + colima the VM shares $HOME and /Users/Shared but not /var/folders (Dir.tmpdir) — and docker silently turns a bind mount from an unshared host path into an empty directory. The prewarm container then reads an empty /run/secrets/WWISE_TOKEN and fails far from the cause (hit for real in snappy's image rebuild today; probe: mounting a mktemp file into alpine yields an empty dir, mounting files under the data root works).

Secret temp files now live under <data-root>/tmp, VM-visible on every supported layout. Sticky world-writable dir (data root is shared between human and agent), files stay 0600, caller still deletes them. Test-first: the new test pins files under Dev::DataRoot.path and off Dir.tmpdir.

Made with Cursor

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[JPDuchesne]

Addressed the security audit in 2a0adc1. Went with the per-identity dir, with one design change from the audit's recommendation: the dirs live directly under the data root (secrets-<uid>, 0700) rather than nested in a shared tmp/ — a shared parent reintroduces the hole one level up, since a world-writable (or attacker-owned) parent's owner can rename a verified dir out from under us after the lstat check. With the dir directly under the data root, the parent chain is the provisioned dev/ (775, group-writable only) under sticky /Users/Shared, so no world-writable link remains.

• Dir.mkdir 0700 + File.lstat verification (real directory, owned by current uid) → typed SecretDirCompromisedError, never a fallback. The blind rescue Errno::EPERM is gone.
• Mode normalized to 0700 only when we own the dir (covers Linux setgid propagation from the data root).
• Day-old dev-secret-* sweep on entry (SIGKILL strands files; macOS never purges the data root, unlike /var/folders).
• Tests pin the lstat properties and cover the symlink-plant, foreign-owner, and sweep paths.

Severity context for the record: on a provisioned machine the original attack required being inside the trust boundary already (dev/ is 775 human:ai, and sticky stops non-owners unlinking others' files) — the live exposure was the unprovisioned-machine pre-own case and the unverified-assumption code smell. Both closed.