Security-Review: PostgreSQL in der Sandbox für gezielte Beweise #37

Worum es geht

Das Security-Review hat in seiner Sandbox keine Datenbank. Was an Policies, Triggern und den Rechten der Rollen hängt, kann es deshalb nur lesen und nicht ausprobieren. Bei der Haustechnik und bei der Handwerkersoftware liegt dort aber der Kern der Trennung von Mandanten und Bereichen.

In den Berichten der letzten acht Pull Requests der Haustechnik steht die fehlende Datenbank jedes Mal. Einer davon (opengewerk/opengewerk-haustechnik#240) wurde allein deshalb rot: zwei Beweislücken, kein Befund.

Entschieden am 12.10.2026: das Review bekommt eine Datenbank, und zwar in der Sandbox.

Wie

• Installieren: PostgreSQL 18 kommt im Schritt "Sandbox vorbereiten" auf den Runner, aus der Paketquelle von PostgreSQL, solange es sudo noch gibt und bevor Code des Pull Requests läuft. Der Runner bringt nur 16 mit, die Haustechnik braucht 18 (uuidv7()). Der Dienst wird nicht gestartet.
• Starten: Das Review startet den Server selbst, als gewöhnlichen Prozess in der Sandbox, mit dem Datenverzeichnis unter .security-review/cache und nur auf dem 127.0.0.1 der Sandbox. Jeder Befehl der Shell hat seinen eigenen Prozessraum, der Server lebt also für die Dauer eines Befehls. Dafür legt der Workflow ein Hilfsskript nach .security-review/: anlegen, starten, den übergebenen Befehl ausführen, anhalten.
• Einrichten je Repository: Port, Rolle und Name der Testdatenbank stehen in der CI des jeweiligen Repositorys. Ob das Hilfsskript sie als Eingabe des Aufrufs bekommt oder das Review sie dort nachliest, zeigt der Probelauf.
• Auftrag: Die Datenbank ist für gezielte Beweise da: ein eigener Gegenversuch, einzelne Testdateien am geänderten Bereich. Die ganze Testreihe bleibt Sache der CI. Startet die Datenbank nicht, ist das kein Befund und keine Beweislücke von selbst; der Bericht sagt es und prüft wie bisher statisch.

Was nicht

• Kein Service-Container und kein Server außerhalb der Sandbox. Docker bleibt abgeschaltet. Ein Server neben der Sandbox, zu dem der Code des Pull Requests eine Verbindung mit Rechten eines Verwalters hat, wäre ein Weg hinaus (COPY ... FROM PROGRAM).
• Die Sandbox wird dafür nicht gelockert. Geht es nur mit freigegebenen Unix-Sockets oder mit einem Server außerhalb, bleibt das Review ohne Datenbank. Dann verlangt der Auftrag stattdessen zu jeder Aussage, die an der Datenbank hängt, den Test des Pull Requests, der sie hält.

Zuerst ein Probelauf

Offen ist, ob PostgreSQL unter bubblewrap überhaupt startet:

• Der Filter der Sandbox sperrt vermutlich Unix-Sockets. Dann läuft der Server nur über TCP (unix_socket_directories = '').
• Der gemeinsame Speicher muss in der Sandbox funktionieren (/dev/shm, sonst mmap).

Geprüft wird an einem Prüfzweig und einem Test-PR in einem Repository, dessen Aufruf auf die SHA des Prüfcommits zeigt, wie zuletzt bei opengewerk/opengewerk-kanzlei#49. Dabei werden Dauer und Kosten je Lauf gemessen. Erst danach werden die Aufrufe der fünf Repositories angehoben.

Abnahme

• Ein Review an einem Pull Request der Haustechnik führt in der Sandbox mindestens eine Testdatei mit Datenbank aus, und der Bericht nennt sie.
• sudo und Docker sind beim Lauf abgeschaltet wie bisher, und die Einstellungen der Sandbox (Netz, Schreiben, Lesen, Variablen) sind unverändert.
• Dauer und Kosten je Lauf sind gemessen, vorher und nachher.
• Die Aufrufe in den fünf Repositories zeigen auf den neuen Commit.