De-Root-Umzug: build_customer_iso.sh-Aufruf per scoped sudo

provisioning-server laeuft auf der neuen anode-VM nicht mehr als root
(siehe kundenplattform.service als Vorbild fuer die Haertung). Der
ISO-Build braucht weiterhin root (CAP_CHOWN/CAP_FOWNER fuers Erhalten
der Datei-Eigentuemer im Squashfs, siehe Kommentar in
build_customer_iso.sh) - deshalb hier per eng gefasster NOPASSWD-
sudo-Regel (/etc/sudoers.d/provisioning-server-iso-build, nur genau
dieser Skriptpfad) statt den ganzen Dienst wieder privilegiert laufen
zu lassen. End-to-End getestet: echter ISO-Build ueber denselben
systemd-Namespace wie der Produktionsdienst, inkl. Loeschbarkeit der
root-erzeugten Ausgabedatei durch den provisioning-server-User.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KMczXJkjyv59Ds3TsDw8H3

app.py

@@ -2462,8 +2462,15 @@ def run_iso_build(build_id, organization_id: str, activation_code: str, wifi_ssi
     volid = compute_iso_volid(organization["name"] if organization else "TUXFLOTTE")
 
     try:
+        # De-Root-Umzug (07.09.2026): der Dienst selbst laeuft nicht mehr als
+        # root, aber build_customer_iso.sh braucht es weiterhin zwingend
+        # (unsquashfs/mksquashfs, CAP_MKNOD - siehe Kommentar dort). Statt den
+        # ganzen Prozess wieder privilegiert laufen zu lassen, nur dieser eine
+        # Aufruf per eng gefasster NOPASSWD-sudo-Regel (siehe
+        # /etc/sudoers.d/provisioning-server-iso-build).
         result = subprocess.run(
             [
+                "sudo",
                 "bash",
                 f"{TUXFLOTTE_INSTALLER_DIR}/scripts/build_customer_iso.sh",
                 MINT_ISO_PATH,