Gegenbuch-Container: Rechte am Bind-Mount selbst geraderuecken

Fehlerbild aus dem echten Betrieb: "mkdir: cannot create directory
'/gegenbuch/schluessel': Permission denied", Container in der
Neustart-Schleife. Ursache: Das Datenverzeichnis kommt als Bind-Mount vom Host;
der Betreiber hatte das Projekt als root geklont, der Container lief aber
direkt als UID 1000 und durfte dort nichts anlegen. Der .gitkeep-Ansatz hatte
stillschweigend angenommen, dass als normaler Benutzer geklont wird - auf einem
Server ist root der Normalfall.

Fix: Der Container startet als root, setzt /gegenbuch per chown auf den
Arbeitsbenutzer (PUID/PGID, Standard 1000) und startet sich per setpriv als
dieser neu. Die eigentliche Arbeit laeuft weiterhin unprivilegiert. Schlaegt
das chown fehl (rootless Docker), gibt es einen Hinweis mit dem passenden
Host-Befehl statt eines stummen Abbruchs.

Verifiziert mit exakt der Ausgangslage: Datenverzeichnis auf root:root gesetzt,
Container gestartet -> laeuft durch, erzeugte Dateien gehoeren 1000:1000, der
private Schluessel liegt mit 0600.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

tools/audit-notary/Dockerfile

@@ -15,9 +15,13 @@ COPY notary.mjs /opt/notary/notary.mjs
 COPY entrypoint.sh /opt/notary/entrypoint.sh
 RUN chmod +x /opt/notary/entrypoint.sh
 
-# Nicht als root laufen. Das Node-Image bringt bereits einen Benutzer mit
-# UID 1000 mit ("node") – der passt zu Bind-Mounts unter ./data/.
-USER node
+# Der Container STARTET als root – aber nur, um die Rechte auf dem
+# Datenverzeichnis geradezuziehen. Danach gibt der entrypoint die Privilegien
+# ab und arbeitet als unprivilegierter Benutzer weiter.
+#
+# Grund: Das Datenverzeichnis kommt als Bind-Mount vom Host. Wer das Projekt
+# als root geklont hat, hat dort root-eigene Verzeichnisse – ein Container, der
+# direkt als UID 1000 startet, kann darin nichts anlegen.
 WORKDIR /gegenbuch
 
 ENTRYPOINT ["/opt/notary/entrypoint.sh"]