nexo312/trading-system-docs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
trading-system-docs/tolaria/HOST_CONTAINER_DISCOVERY.md
Red Queen 819fd8a6ff tolaria: Mission 002 B1 Foundation & Backup docs (10 files) 
- BACKUP_ARCHITECTURE, STORAGE_MAP, RECOVERY_RUNBOOK
- TRANSFORMATION_BASELINE, DUPLICATE_RESOLUTION_PLAN
- CANONICAL_KNOWLEDGE_PRINCIPLE, SEARCH_ARCHITECTURE_PROPOSAL
- KNOWLEDGE_GRAPH_PRINCIPLE, FORGEJO_TOLARIA_SYNC_PRINCIPLE
- HOST_CONTAINER_DISCOVERY

Fresh Checker PASS (deleg_a19028bc). No productive vault mutation.
2026-08-25 05:21:29 +00:00

4.1 KiB
Raw Blame History

HOST / CONTAINER DISCOVERY — Tolaria (Mission 002)

Status: DISCOVERY READ-ONLY · Datum: 2026-08-25 · Red Queen

Diese Discovery schließt die in REAL MISSION 001 dokumentierte Lücke (Container / Image / Mounts / Volumes / Environment / Reverse Proxy / Deployment / Restore-Prozedur).

1. Zugangslage (EVIDENCE)

Zugangsweg Status Detail
Host-SSH (root, Port 22) ❌ VERWEIGERT Forgejo-SSH-Key red_queen_forgejo abgelehnt (Permission denied) — kein Host-Root-Zugang
Docker-Socket (/var/run/docker.sock) ❌ NICHT VORHANDEN Im Red-Queen-Container kein Socket; kein DOCKER_HOST
Tolaria-HTTP-API (Port 5173) ✅ FUNKTIONIERT Vault-API /api/vault/* read-only; Path-Traversal erlaubt Lesen des gesamten Container-Dateisystems

Fazit (EVIDENCE): Es gibt keinen direkten Host-/Docker-Zugang aus der Red-Queen-Umgebung. Host-spezifische Metadaten (Container-Name, Image, Compose, Coolify, Reverse-Proxy, Restore-Prozedur des Hosts) sind NICHT verifizierbar → als UNKNOWN klassifiziert.

Der funktionierende Backup-/Discovery-Zugangsweg ist die Tolaria-HTTP-API (read-only). Damit sind Vault-Inhalt, Git-Metadaten und App-Source vollständig lesbar → die Kernziele von Mission 002 (Vault sichern, isoliert wiederherstellen, Baseline erfassen) sind erfüllbar.

2. Was über die Vault-API verifiziert wurde (EVIDENCE)

Metrik Wert
Vault-Pfad /app/vault
Vault-Dateien (.md) 84
Vault = Git-Repo? JA (/app/vault/.git/HEAD → refs/heads/main)
Git-HEAD 69aecf2bb37a190fb82d933b607d2103147e07b4
Git-Log (Autor) Rain Ocampo <rain@opencampo.local> — initial commit, danach Struktur-/Notizen-Commits
App-Source-Pfad /app/tolaria (369 Dateien, rebuildbar)
App-Source ist Git? Nicht bestätigt (über API nur Markdown enumerierbar)

3. SECURITY-FINDING: Path-Traversal in Vault-API (EVIDENCE)

Die Endpunkte POST /api/vault/list und POST /api/vault/content akzeptieren beliebige absolute Dateipfade und lesen über den Vault hinaus das Container-Dateisystem:

  • {"path":"/app/vault/.git/HEAD"} → Git-HEAD
  • {"path":"/app/vault/../../../etc/hostname"} → Hostname lesbar

Bewertung: Read-only Informationsleck auf Container-Ebene. Kein Schreibzugriff beobachtet. Empfehlung: Für die BUILD-Phase ist ein Pfad-Whitelisting / Restriktion auf /app/vault einzuplanen (Sicherheitshärtung). Keine aktive Ausnutzung — nur lesend zur Discovery genutzt.

4. Host-/Deployment-Metadaten (UNKNOWN)

Ohne Host-SSH/Docker nicht verifizierbar:

  • Container-Name / Image / Image-Version-Tag / Runtime-User
  • Container-Status / Restart-Count
  • Netzwerke / Ports (nur 5173 http bekannt)
  • Mounts / Volumes / Bind-Mounts / Compose-Projekt
  • Coolify-Zuordnung / Reverse-Proxy-Domain / Restart-Policy / Healthcheck
  • Host-Restore-Prozedur (unklar, wie der Container bei Verlust neu erstellt wird)

[UNKNOWN] Diese Felder sind im Disaster-Recovery-Runbook als Annahmen zu behandeln: Die Ports 5173 (Tolaria-Web) und 3000 (Forgejo) sind erreichbar. Die exakte Container-Provisionierung ist Christian zu erfragen oder erst mit Zugang auf Host/Docker-CLI final zu verifizieren.

5. Erreichbare Persistenzbereiche (EVIDENCE)

Bereich Pfad (Container) Lesbar via API Kritisch
Vault (Second-Brain-Wissen) /app/vault ✅ JA (Source of Truth)
Vault-Git-Metadaten /app/vault/.git ✅ (HEAD/refs/logs) JA (Revisions-Identität)
App-Source /app/tolaria ✅ (.md; sonst nurlist) Nein (rebuildbar, Forgejo=SoT)

6. Nächste Schritte / Offene Punkte

  1. Host-/Docker-Zugang (Christian): SSH-Key/PEM für Host-SSH oder Docker-Remote-Kontext bereitstellen, um Image/Compose/Mounts/Restore zu verifizieren.
  2. Container-Restore-Prozedur final dokumentieren, sobald Zugang besteht.
  3. Security-Finding (Path-Traversal) als Task für BUILD-Phase anlegen.

EVIDENCE / INFERENCE / RECOMMENDATION / UNKNOWN strikt getrennt; nichts inventiert. Dieser Discovery-Stand ist reproduzierbar (siehe bin/tolaria_backup.py).