piloto harkaq-trace MEDIDO en builds reales: ceguera-overlay confirmada (0 eventos de store, 206 de binds) y salida validada — marcar /proc/<pid-bwrap>/root cae en el SB del overlay y los paths salen en el idioma de la política; zlib-ng SELLADA b3:93d1da8a al 1er intento; dwarves BLOQUEADA (elfutils sellado sin libdw ⇒ pide variante elfutils-libdw)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
2026-07-17 00:05:54 -04:00
co-authored by Claude Fable 5
parent dac5bbb1f7
commit 7fa12ed7ce
3 changed files with 31 additions and 7 deletions
+19
View File
@@ -52,6 +52,25 @@ accesos condicionales entre corridas (mitigación: la poda sugiere, nunca aplica
contrato que suggest). Piloto: 3 recetas ya instrumentadas (zlib, tar, brotli), en el worker
(el laptop no compila C).
**PILOTO MEDIDO (2026-07-17, worker, builds reales de zlib-ng y dwarves):**
1. **Ceguera-overlay — el hallazgo que corrige el diseño.** `FAN_MARK_FILESYSTEM` sobre el
fs del host (donde vive el store) NO ve los reads que el build hace a través del
`--tmp-overlay` del sandbox: el superbloque del overlay es OTRO, y overlayfs abre los
lower por dentro sin fsnotify en el sb de abajo. Medido: build completo de zlib-ng con
traza sobre el store = **0 eventos**; los binds sí aparecen (206 eventos de `/src` vía
`work/sources`, mismo sb) e incluso los reads host-side de hammer (`recipes/*.toml` al
resolver deps — la traza ya sirve para auditar el hub).
2. **La salida, validada**: marcar `--fs /proc/<pid-bwrap>/root` — el magic-link cruza al
mount-ns y la marca cae sobre el SB DEL OVERLAY. Test sintético en el worker (overlay en
mntns aparte, lector externo): la lectura del lower a través del overlay **aparece** en
la traza. Bonus: los paths salen EN EL NAMESPACE DEL SANDBOX (`/usr/include/zlib.h`) —
el mismo idioma de la política harkaq, sin traducción host↔jaula. Cero código nuevo:
`harkaq-trace --fs /proc/$PID/root --prefix /usr`.
3. **Pendiente de orquestación**: alguien tiene que darle al tracer el pid del bwrap en
vuelo (wrapper sobre `hammer build`, o hammerd). Ese es el siguiente paso de T1.1, y
donde toca coordinar con el harness (carril de Opus) para no duplicar lanzadores.
---
## 2. Capsicum / casper → la taxonomía del cierre §3 (política runtime)