Fix SELinux backup execution context and probe source metadata before downtime

UPDATE_ANLEITUNG.md

@@ -24,7 +24,9 @@ Backups mit zeitweiliger Unterbrechung der konfigurierten Anwendungen.
 5. Crypt-Konfiguration, DB-Dateien, globales DB-Recht `RELOAD` und bei MariaDB
    Zugriff auf Routinen-Metadaten prüfen;
    vorhandene Schlüssel/Passwörter erhalten. Keine automatischen DB-Grants.
-6. Vorprüfung mit geschützten Kopien durchführen. Bei Fehlern bleibt das installierte
+6. Vorprüfung mit geschützten Kopien durchführen. rsync prüft außerdem den Zugriff
+   auf Quellverzeichnisse und deren Attribute in einem privaten temporären
+   Prüfbereich, ohne Datei-Inhalte zu kopieren. Bei Fehlern bleibt das installierte
    Paket samt Anwendungskonfiguration und Timer unverändert.
 7. Einen von SSH unabhängigen systemd-Auftrag `app-backup-upgrade.service` mit
    `--no-block` einreihen und die Sperren an ihn übergeben.
@@ -274,6 +276,41 @@ im Journal protokolliert. Eine längere Pause ohne CPU-Last lässt sich so einem
 konkreten Dienst zuordnen; ohne dessen Journal lässt sich die Ursache der Pause
 nicht aus ihrer Dauer allein bestimmen.
 
+## SELinux: rsync-Zugriff verweigert (Exit 23)
+
+Der Gemini-Lauf vom 10.09.2026 um 14:58 Uhr scheiterte nach drei erfolgreichen
+DB-Dumps beim Kopieren von `/var/www/html`. Das Audit bestätigt rsync im Kontext
+`rsync_t`: Lesen von `httpd_sys_content_t` sowie Attributänderungen und Relabeling
+im Staging wurden verweigert. Zusätzlich wurden geerbte Sperrdeskriptoren beanstandet.
+Die gestoppten Dienste wurden laut Journal wieder gestartet und Nextcloud verließ
+den Wartungsmodus. Es entstand kein vollständiger neuer Sicherungssatz.
+
+Das aktuelle Paket setzt für den Update-Auftrag und den installierten Backup-Dienst
+`SELinuxContext=system_u:system_r:unconfined_service_t:s0` und startet beide über
+`/bin/bash`. **Diese privilegierten Prozesse und ihre Kindprozesse laufen damit
+ohne SELinux-Einschränkung.** SELinux bleibt systemweit aktiv; andere Dienste
+behalten ihre bestehende Policy. Der Installer ändert keine globalen rsync-Booleans,
+keine Quell-Labels und keine Quellberechtigungen. Ein nicht zugelassener Kontext
+führt zu einem sichtbaren Startfehler.
+
+Auf Gemini ist die Bash-Startkette mit diesem Kontext und erfolgreichem
+rsync-Auflisten des Webverzeichnisses unter Enforcing geprüft. Der direkte
+Unit-Start von `/usr/bin/rsync` scheiterte dagegen mit 203/EXEC und bildet die
+Startkette des Pakets nicht ab. Manuelle Unit-Anpassungen sind nicht erforderlich:
+das aktuelle Paket mit denselben Gitea-/Cron-/Mail-Optionen erneut starten.
+
+Vor dem Wartungsmodus prüft das Paket über rsync die Quellverzeichnisse und die
+Übernahme ihrer Verzeichnisattribute in einen privaten temporären Prüfbereich.
+Dabei werden keine Dateiinhalte kopiert. Die Probe erfasst nicht jede untergeordnete
+Datei; der vollständige Kopierlauf und die Remote-Prüfung bleiben erforderlich.
+rsync erhält keine geerbten Sperrdeskriptoren; die Elternprozesse halten die Sperren
+weiter. Der SELinux-Kontext des Backup-Prozesses erscheint im Protokoll.
+
+Bei einem erneuten Fehler `update.log`, die ausgegebene Ergebnisdatei und die
+passenden AVC-Meldungen prüfen. Maßgeblich für den erfolgreichen Abschluss bleibt
+`SUCCESS` in `result.txt`; erst danach aktiviert der Installer den Backup-Timer.
+Eine Wiederherstellungsprobe auf einem separaten System steht weiterhin aus.
+
 ## Paket reproduzieren
 
 Aus einem sauberen, eingecheckten Repository:
@@ -290,12 +327,14 @@ Das ausführbare Paket ausschließlich über euren vertrauenswürdigen Kanal bez
 
 ## Verifikation der Lieferung
 
-41 Container-Tests sowie ShellCheck und Shell-Syntaxprüfung erfolgreich.
+44 Container-Tests sowie ShellCheck und Shell-Syntaxprüfung erfolgreich.
 Die Tests enthalten echte MariaDB-Dumps/Imports und lokale rclone-Crypt-Roundtrips;
 systemd/occ und die systemd-run-Übergabe sind simuliert. Das Übergabemodell
 berücksichtigt jetzt das Warten auf den oneshot-Startauftrag: Der Regressionstest
 scheiterte mit dem alten Code und war nach dem Fix erfolgreich. Geprüft sind auch
 abgewiesene Übergaben, eingereihte Worker trotz fehlgeschlagener Antwort und
 persistente Fehlerprotokolle bei belegter Update-Sperre. Die tatsächliche
-Server-/OneDrive-Prüfung erfolgt beim ersten Paketlauf. Ein fachlicher Restore
+SELinux-Durchsetzung wird im Debian-Testcontainer nicht nachgebildet; der erfolgreiche
+Bash-/rsync-Lesetest auf Gemini wurde separat vom Betreiber durchgeführt. Die vollständige
+Server-/OneDrive-Prüfung erfolgt beim Paketlauf. Ein fachlicher Restore
 auf einem separaten Testsystem bleibt erforderlich.