Hastanelerin idari hiyerarşisinde görev dağılımı ve yetki sınırları hayati bir düzen üzerine kuruludur. Bir hastanenin başhekimi, poliklinik koridorlarının zeminini paspaslamak için eline vileda kovasını almaz.
Şimdi gözünüzün önüne absürt bir başhekim getirin: Gece yarısı "Temizlikçiler bu işi beceremez, ben en yetkili kişiyim, bütün hastaneyi kendi ellerimle temizleyeceğim" diyerek odasından çıkıyor. Ameliyat önlüğünü giyiyor, yerleri paspaslıyor. Ancak başhekimin bir takıntısı vardır: Paspasladığı her muayene odasının, ecza deposunun ve ameliyathane kapısının kilidine kendi özel başhekimlik çelik mührünü vuruyor!
Sabah saat 08:30'da nöbetçi hekimler, hemşireler ve hastalar polikliniğe gelir. Muayene odalarının kapı koluna yapışırlar: Kilitli! Başhekimlik çelik mührü vardır; hekimlerin veya hemşirelerin anahtarı o kapıyı açamaz. Tüm hastanede poliklinikler durur, ameliyatlar iptal edilir; çünkü başhekim aşırı yetkisiyle yerleri temizlemiş ama arkasındaki tüm kapıları sıradan personelin yüzüne kilitlemiştir!
Linux sunucu yönetiminde ve sistem mimarisinde her hafta yüzlerce web uygulamasını sabahın erken saatlerinde felç eden en büyük operasyonel basiretsizlik tam olarak bu başhekim mühürlemesi faciasıdır: Uygulama düzeyindeki Cron Job'ları (zamanlanmış görevleri) doğrudan sunucunun root kullanıcısıyla çalıştırmak.
Bir Laravel, WordPress veya özel PHP tabanlı e-ticaret sitesi... Sistemde arka planda yapılması gereken rutin işler vardır:
Eski önbellek dosyalarını temizlemek (cache:clear),
Ürün görsellerinden yeni webp türevleri üretmek,
Arama motorları için sitemap XML dosyası derlemek,
Süresi dolmuş kullanıcı oturumlarını (sessions) süpürmek.
Sistemi kuran geliştirici veya acemi sistem yöneticisi SSH ile sunucuya root olarak bağlanır. Terminale şu komutu yazar:
crontab -e
Yani sistemin en kutsal, en sınırsız kullanıcısı olan root kullanıcısının zamanlanmış görev tablosunu açar. Ve dosyanın içine şu görevi ekler:
# Her gece 03:00'te sitemap ve önbellek yenile:0 3 * * * /usr/bin/php /var/www/html/artisan schedule:run > /dev/null 2>&1
Geliştirici kendi kendine o meşhur amatör gerekçeyi sunar: "root ile çalıştırayım ki izin hatası (Permission Denied) falan almasın, tıkır tıkır çalışsın!"
İlk bakışta her şey kusursuz görünür. Gece saat 03:00 olur; cron tetiklenir, PHP scripti çalışır ve görev başarıyla tamamlanır.
Fakat arka planda, başhekim o ölümcül çelik mührü tüm kapıların üzerine vurmuştur!
Linux dosya sisteminde değişmez bir fizik kuralı vardır: Bir dosyayı hangi kullanıcı oluşturduysa, o dosyanın sahibi (Owner) ve grubu (Group) o kullanıcıya ait olur!
Cron görevi root yetkisiyle çalıştığı için:
Oluşturulan yeni log dosyası: /var/www/html/storage/logs/laravel.log -> Sahibi: root:root (İzin: 0644 veya 0600)
Oluşturulan yeni önbellek dizini: /var/www/html/bootstrap/cache/ -> Sahibi: root:root
Sabah mesaisi başlar. İlk ziyaretçi web sitesine girer: sirketadi.com.
Ziyaretçiyi kapıda web sunucusu karşılar: Nginx veya Apache. Web sunucusu güvenlik gereği asla root yetkisiyle çalışmaz; izole edilmiş, kısıtlı bir servis kullanıcısıyla çalışır: www-data veya nobody.
Ziyaretçi sayfayı açtığında uygulama PHP kodu üzerinden bir log satırı yazmak ister: "Kullanıcı ana sayfaya girdi."
www-data kullanıcısı eline kalemi alır, /storage/logs/laravel.log dosyasına yazmaya kalkar.
Ve Linux çekirdeği (Kernel) tokadı indirir:
The stream or file "/var/www/html/storage/logs/laravel.log" could not be opened: failed to open stream: Permission denied
İşletim sistemi der ki: "Hop dur bakalım! Bu dosyanın sahibi root'tur ve sadece root yazabilir! Sen zavallı bir www-data kullanıcısısın, bu dosyaya tek bir harf bile yazamazsın!"
Uygulama log dosyasına yazamadığı için panikler; hata fırlatmak ister ama hata günlüğüne de yazamadığı için sistem doğrudan 500 Internal Server Error basarak komaya girer!
Sabah siteye giren binlerce müşteri bembeyaz bir ekranda 500 hatası görür. Şirket genel müdürü bilgi işlem sorumlusuna bağırır: "Gece sitemize kim dokundu? Dün akşam çalışan site sabah nasıl çöker?"
Yazılımcı sunucuya girer; hakikaten koda kimse dokunmamıştır! Kod aynı koddur; fakat o gece çalışan root cron'u, uygulamanın kendi evindeki kapı kilitlerini değiştirmiştir.
Bir hastanede yerleri başhekimin değil temizlik görevlisinin paspaslaması gerektiği gibi; web uygulamasının görevlerini de root değil, o uygulamanın gerçek sahibi olan kullanıcı koşturmalıdır:
Uygulama Kullanıcısının Crontab'ını Kullanın:
Cron görevlerini asla root tablosuna yazmayın! Görevi doğrudan web sunucusu kullanıcısının (www-data) veya cPanel kullanıcısının (firma) crontab'ına tanımlayın:
# Ubuntu / Debian için www-data adına cron aç:crontab -u www-data -e# cPanel / CloudLinux için ilgili kullanıcı adına aç:crontab -u firma -e
Bu sayede cron çalıştığında üretilen tüm log ve önbellek dosyalarının sahibi otomatik olarak www-data:www-data olur; web sunucusu hiçbir izin engeline takılmadan dosyaları okur ve yazar.
Eğer root İle Çalışmak Zorundaysa (Sahiplik Düzeltme):
Eğer script mutlaka root yetkisi gerektiren bir sistem göreviyse, scriptin en son satırına mutlaka sahiplikleri web kullanıcısına iade eden şu cerrahi dikişi ekleyin:
UMASK Disiplini: Sunucu yapılandırmasında umask değerini (umask 002) doğru ayarlayarak, yeni oluşturulan dosyaların grup üyeleri tarafından da yazılabilir olmasını garanti altına alın.
Aşırı yetki güç değil, felakettir. Yerleri temizleyeceğim diye hastanenin tüm kapılarını kilitleyen başhekim nasıl tüm sağlık sistemini kilitliyorsa; "kolaylık olsun" diye cron'u root ile koşturan sistem yöneticisi de kendi uygulamasının celladı olur. Linux'ta yetki hiyerarşisi keyfi bir bürokrasi değildir; sistemin kendi kendini imha etmesini engelleyen en kutsal emniyet subabıdır.