Auf dem Ticket steht „Berechtigung verweigert“ für „storage/logs“. Die schnelle Antwort: „chmod -R 777 storage“. Die App funktioniert wieder. Drei Monate später wird eine in „storage/uploads“ hinterlegte „.php“ ausgeführt, da nginx dieses Verzeichnis noch bedient.
Webberechtigungen sind keine Unix-Bürokratie: Trennung zwischen Code, Daten, Uploads und Ausführung.
Empfohlenes Modell
Code (Git Deploy): Mensch/CI-Besitzer, Web schreibgeschützt. Daten („Speicher“, Cache): gezieltes Schreiben von WWW-Daten. Uploads: Teilbaum ohne Interpreter.
| Pfad | Eigentümer | Mode | Hinweis |
|---|---|---|---|
| app/ | Bereitstellen:www-data | 750/640 | kein Upload |
| Lagerung/ | WWW-Daten | 770 dirs | Protokolle, Cache |
| öffentlich/Uploads | WWW-Daten | 750 | noexec wenn möglich |
umask und systemd
umask 027 oder 002 je nach Gruppenmodell. PHP-FPM „user=www-data“, separater Pool pro mandantenfähige App.
Vermeiden Sie es, Bereitstellungsskripte als Root ohne abschließenden Chown auszuführen.
nginx / Apache
location ^~ /uploads/ { location ~ \.php$ { alles verweigern; } } – Ausführung blockieren, auch wenn eine .php-Datei hochgeladen wird.
Separater vhost-Benutzer bei eingeschränktem Shared Hosting.
ACL für krumme Fälle
setfacl -m u:www-data:rwX storage ohne die Welt zu öffnen. Setzen Sie die ACL nach der Wiederherstellung des Backups zurück – oft vergessen.
Automatisierte Prüfung
Skript nach der Bereitstellung: schlägt fehl, wenn „find . -perm -0002`. Benachrichtigungen zu SUID neu. Dokumentieren Sie die vorübergehende Ausnahme mit Ticket und Ablaufdatum.
Express-Berechtigungsprüfung
„Bash Finden Sie /var/www -type f -perm -0002 finde /var/www -type d -perm -0002 find /var/www -name '.php' -path '/uploads/*'
Richtig: chown deploy:www-data, chmod 640 Dateien / 750 Verzeichnisse, nginx verweigert PHP-Uploads.
Dokumentieren Sie Ausnahmen mit Ticket und Ablaufdatum. Scannen Sie das CI nach der Bereitstellung erneut.
Entwicklerschulung: „Berechtigung verweigert“ → strace/id/groups vor chmod.
Ein einziger Upload eines weltweit beschreibbaren Verzeichnisses reicht für kleine Kompromisse in der CMS-Lieferkette aus.
SELinux/AppArmor auf gehärteten Distributionen: chcon ist manchmal nach der Bereitstellung erforderlich – Dokumentkontexte, nicht nur chmod.
Container: Volume-Mount-UID-Zuordnung – Berechtigung verweigert, mysteriös, oft UID-Host ≠ Container-Benutzer.
## Technische Schuldenerlaubnisse
Prüfvermächtnis: Der alte Anbieter „chmod 777 storage“ ist nirgends dokumentiert. Sprint-Behebungsplan: Nginx Deny + ACL + Chown.
PHP-FPM-Poolbenutzer pro Multi-Tenant-Client, wenn gemeinsam genutzt, benutzerdefiniert – Isolierung durch Unix-Benutzer > chmod-Welt.
Git verfolgt standardmäßig keine Berechtigungen – Post-Checkout-Hook-Wiederherstellungsmodi, falls erforderlich.
## Betriebszusammenfassung
Die richtigen Berechtigungen beim Webhosting trennen Lesen, Schreiben und Ausführen nach Rollen: „Deploy“ schreibt Code, „www-data“ schreibt Uploads und Cache, niemand führt PHP in Uploads aus. Das gemeinsame System kompensiert manchmal mit open_basedir; VPS erfordert explizite Disziplin.
Webshell-Prüfung nach dem Vorfall: chmod allein reicht nicht aus – Nginx verweigert die Ausführung, Rotationsgeheimnisse, Vektor-Upload-Analyse. Integrieren Sie Scanberechtigungen in die CI-Bereitstellung. Training: Berechtigung verweigert → Besitzer/Gruppe vor Modus.
## Schritt-für-Schritt-Anleitung
1. Identifizieren Sie den Benutzer PHP-FPM („ps aux | grep php-fpm“).
2. Listen Sie den Web-Root des aktuellen Besitzers auf („namei -l /var/www/app/public“).
3. Wenden Sie „deploy:www-data 750/640“ auf den Code an.
4. Speicherung und Uploads von 770/750 WWW-Daten.
5. Nginx verweigert PHP in Uploads.
6. Scannen Sie CI weltweit beschreibbar.
7. Ausnahmen dokumentieren.
Bei böswilligem Upload-Vorfall: vhost isolieren, Datei zur Analyse aufbewahren, DB-Passwort rotieren, wenn SQL-Injection vermutet wird, Berechtigungen von IaC wiederherstellen, keine manuelle CHMOD-Panik.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
## CMS
WP lädt Nicht-Exec-Laravel-Speicher hoch, der nur beschreibbar ist. Symlink-Bereitstellungsberechtigungen für den aktuellen Stand.
:::Hinweis
**Denken Sie daran.** Zielbesitzer/-gruppe und ACL korrigieren; 777 ist eine Sicherheitsschuld, keine Lösung.
:::
:::Höhepunkt
**Ein rekursiver chmod ist die Berechtigungsversion einer „DROP TABLE“ – schnell, irreversibel ohne Backup und oft nutzlos.**
:::
## Entscheide dich und gehe ohne blinden Fleck voran
1. **Identifizieren Sie den PHP-FPM-Benutzer** – „namei -l“ im Web-Root, Eigentümer „deploy:www-data“.
2. **Wenden Sie 750/640 auf den Code an** – Speicherung und Uploads 770/750, Nginx verweigert PHP in Uploads.
3. **Weltweit beschreibbar scannen** – nach der Bereitstellung im CI nach Ausnahmen mit Ticket und Ablaufdatum suchen.
4. **Schule die Entwickler** – Berechtigung verweigert → strace/id/groups vor chmod 777-Panik.
5. **Wiederherstellung von IaC** nach einem böswilligen Upload-Vorfall – kein manuelles Notfall-chmod.
Shared vs. VPS: Vergleichen Sie die Grenzwerte im [Verzeichnis](/de/verzeichnis/) und in unseren Sicherheitsleitfäden (/fr/guides/).
## Häufig gestellte Fragen
### chmod 755 oder 775 für eine Website?
755 für statische Dateien, wenn www-data alleine liest. 775 nur, wenn mehrere Benutzer in der Gruppe schreiben müssen – strenge Gruppe, niemals weltweit beschreibbar.
### Eigentümer www-data oder bereitstellen?
App-Dateien: Deploy: www-data 640, Ordner 750. Uploads: www-data beschreibbar, PHP-Ausführung im Upload-Verzeichnis über Nginx deaktiviert.
### ACL vs. rekursiver chmod?
setfacl für bestimmte Fälle (deploy + www-data). chmod -R 777 ist ein Anti-Pattern, das den tatsächlichen Benutzer-/Gruppenkonflikt verbirgt.
### Wie auditiert man?
Weltbeschreibbar finden, unerwartete SUID finden, Upload-Pfade überprüfen. Integrieren Sie es in CI oder ein Post-Deployment-Skript.
---
Nächster Fehler: Berechtigung verweigert: Besitzer vor Modus ändern – immer in dieser Reihenfolge.