# Astra: security review of stage B's tenant-directory reads and writes

**Review** cfb4314d..3194d674 on `region-ha-1b-next-build`. The two commits are dca370c2 (reads) and 3194d674 (writes).

**Context.** Relocation installs and flushes nested instance rows. The instance directory is writable by the tenant. Before these commits, stage B read and wrote it with plain path calls. That meant a planted symlink, FIFO or oversized file could redirect the agent's reads or writes, block it, or exhaust its memory.

**The fix.** Every read and write now goes through main's `instancefs`, the same code main's instance-key path uses:
- `readInstanceFile`, `EnsureDirBeneath`, `WriteAtomic` and `RemoveBeneath`;
- a new `OpenDirBeneath` and `OpenRootBeneath` (which builds an `os.Root` from the open directory via `/proc/self/fd/N`);
- a new `hostfiles.RestoreRoot`/`SyncDirAt`, with `Restore`/`SyncDir` delegating to them.

**Judge:**
1. Can a tenant still redirect, block or exhaust any agent read or write in stage B's relocation flush or install? Consider symlinks, FIFOs, hard links, oversized files, and races between check and use.
2. Is `OpenRootBeneath` via `/proc/self/fd` sound? Can the link resolve to anything other than the opened directory?
3. Does `RestoreRoot` stay inside the root? `Restore` still checks then opens within it. Is that only a denial-of-service risk, or worse?
4. Do `Restore`/`SyncDir` behave exactly as before for main's callers (moves)?
5. Is there any second implementation of a safe read or write?

Give findings P1/P2/P3 with file:line, then a verdict.