archive/docs/RET-11-NACHTRAG-CHATTR-UNTERSUCHUNG.md

@@ -178,3 +178,100 @@ externes Object-Lock-fähiges Storage-Backend (siehe Alternative 8).
 Dieser Nachtrag gilt als abschließende Untersuchung; eine erneute
 Prüfung derselben Frage in künftigen QA-Runden ist nicht nötig, sofern
 sich die Host-Konfiguration (privilegiert/unprivilegiert) nicht ändert.
+
+---
+
+## RET-15 Nachtrag: Host-Suche und Ergebnis
+
+Datum: 2026-10-16
+
+Bezug: RET-15 (Folgeticket aus dieser Untersuchung) verlangt einen
+echten End-zu-Ende-Nachweis auf einem tatsächlich `chattr +i`-fähigen
+Host, statt eine erneute Grundsatzuntersuchung der oben bereits
+geprüften und verworfenen Alternativen. Dieser Abschnitt dokumentiert
+ausschließlich die Suche nach einem solchen Host und deren Ergebnis.
+
+### Vorgehen
+
+1. Repoweite Suche nach allen im Projektkontext dokumentierten Hosts:
+   `grep -rhoE "192\.168\.1\.[0-9]+" --include="*.md"` über den
+   gesamten frischen Checkout liefert genau drei IPs: `192.168.1.131`,
+   `192.168.1.204` (beide bereits oben als unprivilegierte LXC-
+   Container auf ZFS-Root identifiziert) und `192.168.1.236`
+   (referenziert in `android/dms-capture/docs/INT-21-PRUEFPROTOKOLL.md`
+   als Android-SDK-Build-Host). Kein weiterer Host ist in der
+   Projektdokumentation (`docs/`, `DEVLOG.md`, Kanban-Boards,
+   Prüfprotokolle) als erreichbar oder privilegiert vermerkt.
+2. Host 236 war über SSH erreichbar (`root@192.168.1.236`). Vor dem
+   eigentlichen `chattr`-Test wurde der Container-Typ geprüft:
+
+   ```
+   $ systemd-detect-virt
+   lxc
+   $ cat /proc/self/uid_map
+            0     100000      65536
+   $ df -T /
+   rpool/data/subvol-1236-disk-0  zfs  ...  /
+   ```
+
+   Identisches Bild wie bei Host 204/131: UID 0 im Container ist auf
+   UID 100000 im Proxmox-Host gemappt (unprivilegierter Container,
+   ZFS-Root). `capsh --print` zeigt `cap_linux_immutable` zwar im
+   Bounding-Set, was laut der oben belegten Kernel-Prüfung
+   (`capable(CAP_LINUX_IMMUTABLE)` gegen den initialen User-Namespace,
+   nicht namensraum-bewusst) für sich genommen nichts aussagt.
+3. Realer Test trotzdem durchgeführt (synthetische Testdatei, keine
+   Produktivdaten):
+
+   ```
+   $ echo "synthetic-test-content-ret15" > /tmp/ret15_probe.txt
+   $ chattr +i /tmp/ret15_probe.txt
+   chattr: Operation not permitted while setting flags on ret15_probe.txt
+   $ echo $?
+   1
+   ```
+
+   Testdatei anschließend entfernt (`rm -f /tmp/ret15_probe.txt`).
+
+### Ergebnis
+
+Host 236 ist, wie 204 und 131, ein unprivilegierter LXC-Container und
+zeigt denselben `EPERM`-Fehlschlag. Er ist damit **kein** geeigneter
+Host für den in RET-15 AC1/AC2 geforderten Nachweis. Im gesamten
+projektbekannten, erreichbaren Infrastruktur-Bestand (131, 204, 236)
+gibt es keinen Host mit echten, nicht nur namensraum-gemappten
+Root-Rechten.
+
+Eine Ausweitung der Suche auf den darunterliegenden Proxmox-Hypervisor
+selbst oder auf weitere, im Projekt nicht dokumentierte Hosts wurde
+NICHT vorgenommen — das wäre keine "bekannte, projektkontextbezogene"
+Umgebung mehr, sondern eine Grundsatz-Infrastruktur-Recherche außerhalb
+des RET-15-Scopes (siehe "Nicht Bestandteil" im Ticket).
+
+**AC1/AC2 bleiben damit offen, wie bereits im ursprünglichen Nachtrag
+festgehalten.** Das ist nach den 8 bereits geprüften Alternativen und
+dieser zusätzlichen, ergebnislosen Host-Suche ein ehrliches, nicht
+weiter durch Workarounds umgehbares Ergebnis — keine Lücke in der
+Untersuchung, sondern eine reale Grenze der aktuell verfügbaren
+Infrastruktur.
+
+**Bedingung, die den Nachweis ermöglichen würde** (unverändert
+gegenüber der Einschätzung oben, hier noch einmal explizit als Antwort
+auf RET-15 Prüfung 2 festgehalten):
+
+- Ein tatsächlich privilegierter Produktions-Host/Container
+  (`unprivileged: 0` in der Proxmox-Konfiguration, oder eine VM/
+  Bare-Metal-Maschine) mit `chattr`-fähigem Dateisystem (ext4, XFS,
+  Btrfs; ZFS plausibel, aber auf keinem der verfügbaren Hosts
+  verifizierbar) — dann liefe derselbe bereits implementierte und
+  fail-closed abgesicherte Code (`wormstore.Put`/`ImmutableLockSupported`)
+  real durch, ohne jede Codeänderung.
+- Ersatzweise ein Architekturwechsel auf ein echtes S3/MinIO-Backend
+  mit aktiviertem Object-Lock Compliance-Mode (bereits als Alternative 8
+  oben vermerkt) — das verlagert die Durchsetzung vom Kernel-Dateisystem-
+  Flag auf den Storage-Backend-Prozess und wäre damit unabhängig von der
+  Privilegstufe des Containers, in dem NEXARCH läuft.
+
+Keine Änderung an `wormstore.go` oder an anderem Produktivcode. Kein
+neues Paralleldokument — dieser Abschnitt ergänzt ausschließlich den
+bestehenden Nachtrag.