Freigaben einbinden, apt-Installation und RPC-Neustart korrigiert

Drei Fehler, alle drei gemessen statt vermutet.

1. Freigaben wurden nie eingebunden ("mount error(1): Operation not
   permitted"). Ursache war NICHT der Mount-Namensraum, sondern
   SystemCallFilter=@system-service: darin fehlen mount/umount2, und
   SystemCallErrorNumber=EPERM macht daraus genau diese Meldung. Nachgewiesen
   in einem nachgebauten Sandkasten: mit "@mount" gelingt die Einbindung,
   ohne nicht. Die Unit von TESM erlaubt jetzt "@system-service @mount"; alles
   andere an der Haertung bleibt. Der zuvor eingebaute Umweg ueber nsenter ist
   zurueckgenommen -- RestrictNamespaces=yes verbietet setns, er konnte nie
   funktionieren.

   Eingebunden wird damit im Namensraum des Webprozesses. Deshalb ist die
   Aufraeumaufgabe fuer abgelaufene Einbindungen aus dem Ueberwachungsdienst in
   den Webprozess gewandert: ein anderer Dienst sieht diese Einbindungen nicht
   und haette Datenbankzeilen als geloest markiert, waehrend die Freigabe
   eingebunden blieb.

2. apt-Installationen aus der Oberflaeche scheiterten mit "dpkg returned an
   error code (1)". Der Sandkasten wird an dpkg und dessen Maintainer-Skripte
   weitervererbt; mit ProtectKernelLogs=yes liefert "dmesg" ein EPERM und ein
   Postinst-Skript bricht daran ab. apt laeuft jetzt ueber systemd-run, also
   von PID 1 gestartet und damit ohne unsere Haertung.

3. Der RPC-Neustart loeste SSH aus. run_reboot entschied den Weg anhand von
   device["category"] -- und dieser Schluessel bedeutet je Herkunft etwas
   anderes: die Wartungsabfrage legt die Kategorie der *Zugangsdaten* darunter,
   inventory.get_device die des *Geraets*. Ueber die Statusuebersicht kam ein
   Windows-Geraet mit leerer Geraetekategorie an, wurde fuer Linux gehalten und
   ueber SSH auf Port 22 angesprochen, bis das Zeitlimit griff. Der Weg wird
   jetzt uebergeben -- entschieden wird er ohnehin schon vorher in
   restart.resolve. Ausserdem zeigte die Neustart-Historie alles ausser "ssh"
   als "PoE-Port"; RPC hat jetzt einen eigenen Eintrag.

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

deploy/systemd/tesm.service

@@ -59,7 +59,20 @@ RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK
 LockPersonality=yes
 MemoryDenyWriteExecute=no
 SystemCallArchitectures=native
-SystemCallFilter=@system-service
+# "@mount" zusaetzlich zu @system-service: die Dateifreigaben werden ueber
+# mount.cifs eingebunden, und @system-service enthaelt mount/umount2 nicht.
+# Ohne diese Ergaenzung scheitert jede Einbindung mit "mount error(1):
+# Operation not permitted" -- gemessen, und zwar unabhaengig von Rechten,
+# Zugangsdaten und Mount-Optionen: aus einer normalen Root-Shell gelingt
+# derselbe Aufruf sofort. Der Umweg ueber nsenter in den Namensraum des Wirts
+# ist keine Alternative, weil "RestrictNamespaces=yes" setns verbietet.
+#
+# Eingebunden wird damit im Mount-Namensraum *dieses* Dienstes. Das ist genau
+# richtig: nur er liest die Dateien, andere Prozesse haben dort nichts zu
+# suchen, und mit dem Dienst verschwinden die Einbindungen wieder. Die
+# Aufraeumaufgabe fuer abgelaufene Einbindungen laeuft deshalb im Webprozess --
+# der Ueberwachungsdienst koennte sie nicht einmal sehen.
+SystemCallFilter=@system-service @mount
 SystemCallErrorNumber=EPERM
 # Bewusst **kein** einschraenkendes CapabilityBoundingSet: sudo braucht
 # CAP_SETUID/CAP_SETGID, und der Helfer dahinter braucht Root. Was hier fehlt,

deploy/tesm-helper

@@ -258,19 +258,17 @@ case "$verb" in
     # Kommandozeile (Prozessliste) und nie ueber die Umgebung
     # (/proc/<pid>/environ).
     read_stdin_limited > "$creds"
-    # Der aufrufende Dienst laeuft in einem eigenen Mount-Namensraum
-    # (ProtectSystem, PrivateTmp, ReadWritePaths). Ein Einbinden *darin*
-    # scheitert mit "mount error(1): Operation not permitted" -- gemessen: mit
-    # denselben Optionen und denselben Zugangsdaten gelingt es aus einer
-    # normalen Root-Shell sofort. Deshalb wird im Namensraum des Wirts
-    # eingebunden; von dort wird der Mount in den Namensraum des Dienstes
-    # weitergegeben (er haengt als "slave" darunter), die Anwendung sieht ihn
-    # also. Die Zugangsdatei unter /run ist ueber die Grenze lesbar, /run ist
-    # nicht privatisiert.
-    im_wirt=(nsenter --mount=/proc/1/ns/mnt --)
-    command -v nsenter >/dev/null 2>&1 || im_wirt=()
-    "${im_wirt[@]}" mkdir -p "$target"
-    if "${im_wirt[@]}" mount -t cifs "$share" "$target" \
+    # Eingebunden wird im Mount-Namensraum des aufrufenden Dienstes -- absichtlich:
+    # nur dieser Dienst liest die Dateien, und mit ihm verschwinden die
+    # Einbindungen wieder. Damit der Syscall durchkommt, braucht die Unit
+    # "@mount" im SystemCallFilter. Ohne das scheitert es mit
+    # "mount error(1): Operation not permitted"; gemessen war der Syscall-Filter
+    # die Ursache, nicht der Namensraum. Ein Umweg ueber nsenter in den
+    # Namensraum des Wirts ist keine Option -- "RestrictNamespaces=yes"
+    # verbietet setns, und das Recht dafuer wieder aufzugeben waere teurer als
+    # der Gewinn.
+    mkdir -p "$target"
+    if mount -t cifs "$share" "$target" \
          -o "credentials=$creds,uid=$(id -u tesm 2>/dev/null || echo 0),gid=$(id -g tesm 2>/dev/null || echo 0),file_mode=0640,dir_mode=0750,vers=3.1.1,seal"
     then
       shred -u "$creds" 2>/dev/null || rm -f "$creds"
@@ -282,13 +280,12 @@ case "$verb" in
 
   umount)
     check_mount_target "${1:?Ziel fehlt}"
-    # Gegenstueck zu mount-cifs: der Mount liegt im Namensraum des Wirts, also
-    # muss er auch dort geloest werden. Ein umount im Dienst-Namensraum wuerde
-    # ihn nur dort ausblenden und die Freigabe bliebe eingebunden.
-    im_wirt=(nsenter --mount=/proc/1/ns/mnt --)
-    command -v nsenter >/dev/null 2>&1 || im_wirt=()
-    "${im_wirt[@]}" umount -l "$1" || true
-    "${im_wirt[@]}" rmdir "$1" 2>/dev/null || true
+    # Gegenstueck zu mount-cifs, und deshalb im selben Namensraum: loesen kann
+    # nur, wer die Einbindung auch sieht. Ein Aufruf aus einem anderen Dienst
+    # greift ins Leere -- genau deshalb laeuft die Aufraeumaufgabe fuer
+    # abgelaufene Einbindungen im Webprozess und nicht im Ueberwachungsdienst.
+    umount -l "$1" || true
+    rmdir "$1" 2>/dev/null || true
     ;;
 
   apt-install)
@@ -296,9 +293,27 @@ case "$verb" in
     for package in "$@"; do
       check_in_list "$package" "${PACKAGES_ALLOWED[@]}" || fail "Paket nicht erlaubt: $package"
     done
+    # apt laeuft ausserhalb des Sandkastens des aufrufenden Dienstes. Der wird
+    # sonst an dpkg und dessen Maintainer-Skripte weitervererbt, und dort
+    # scheitert etwas voellig Beilaeufiges: mit "ProtectKernelLogs=yes" gibt
+    # "dmesg" ein EPERM zurueck, ein Postinst-Skript bricht daran ab, und dpkg
+    # endet mit Code 1 -- die Installation schlaegt fehl, obwohl mit dem Paket
+    # alles in Ordnung ist. Gemessen und mit systemd-run reproduzierbar
+    # behoben: PID 1 startet den Prozess, also ohne unsere Haertung.
     export DEBIAN_FRONTEND=noninteractive
-    apt-get update -qq
-    apt-get install -y -qq "$@"
+    if command -v systemd-run >/dev/null 2>&1 && [[ -S /run/dbus/system_bus_socket ]]; then
+      # Zwei getrennte Aufrufe, damit keine Shell dazwischen steht: die
+      # Paketnamen gehen als eigene Argumente an apt-get, nicht durch eine
+      # Kommandozeile, die sie erst wieder zerlegen muesste.
+      ausserhalb=(systemd-run --wait --pipe --collect --quiet
+                  --setenv=DEBIAN_FRONTEND=noninteractive)
+      "${ausserhalb[@]}" apt-get update -qq
+      "${ausserhalb[@]}" apt-get install -y -qq "$@"
+    else
+      # Kein systemd (Container, Entwicklungsrechner): direkt, wie bisher.
+      apt-get update -qq
+      apt-get install -y -qq "$@"
+    fi
     ;;
 
   certbot-issue)