Dizinler Neden 755, Dosyalar Neden 644 Olmalı?
Linux dosya izin sisteminde dizinler ve dosyalar için çalıştırma (execute) biti farklı anlamlar taşır. Bir dizinde execute biti, o dizinin içine girilebilmesi ve içeriğinin listelenebilmesi anlamına gelir; dosyalarda ise sahibinin ve grubun dosyayı çalıştırabilmesini ifade eder. Web sunucusunun (Apache, Nginx/PHP-FPM) WordPress dosyalarını okuyup tarayıcıya sunabilmesi için dizinlerin girilebilir ve dosyaların okunabilir olması gerekir; bu iki koşul sağlanmadan site hiç açılmaz.
755 izni (drwxr-xr-x) bir dizinin sahibine okuma/yazma/girme, grup ve diğerlerine ise yalnızca okuma ve girme hakkı verir. 644 izni (-rw-r--r--) ise bir dosyanın sahibine okuma/yazma, grup ve diğerlerine yalnızca okuma hakkı verir. Her iki izinde de ortak nokta, diğerleri (others) için yazma hakkının kasıtlı olarak kapalı tutulmasıdır: bu sayede paylaşımlı bir sunucuda çalışan başka bir kullanıcı veya süreç, izin verilmeden dosyaları değiştiremez, silemez ya da üzerine kötü amaçlı kod ekleyemez.
Bu ayrım özellikle paylaşımlı hosting ortamlarında önemlidir, çünkü aynı fiziksel sunucuda onlarca farklı hesap ve süreç çalışıyor olabilir. Dosya sahibi ve grup dışındaki herkes için yazma hakkının kapalı olması, bir hesabın diğerinin dosyalarına yazamamasını garanti eden temel katmandır.
WordPress Codex'in Önerdiği İzin Tablosu
Aşağıdaki tablo, WordPress Codex'in "Changing File Permissions" belgesinde yer alan resmi önerilen izinleri özetler.
| Konum | İzin | Sembolik Gösterim |
|---|---|---|
| Tüm dizinler | 755 | drwxr-xr-x |
| Tüm dosyalar | 644 | -rw-r--r-- |
| wp-config.php | 440 veya 400 | -r--r----- |
| .htaccess | 644 | -rw-r--r-- |
| wp-content/ | 755 | drwxr-xr-x |
| wp-content/uploads/ | 755 | drwxr-xr-x |
Bu izinleri tek tek elle ayarlamak yerine, WordPress kurulum dizininin kök klasöründen çalıştırılacak iki komutla toplu olarak uygulanabilir:
find /path/to/wordpress/ -type d -exec chmod 755 {} \;
find /path/to/wordpress/ -type f -exec chmod 644 {} \;
İlk komut yalnızca dizinleri (-type d) hedef alıp her birine 755 uygular; ikinci komut yalnızca dosyaları (-type f) hedef alıp her birine 644 uygular. Bu iki komut çalıştırıldıktan sonra wp-config.php ve .htaccess gibi özel dosyalar için ayrı, daha sıkı bir chmod komutu ek olarak çalıştırılmalıdır — çünkü toplu komut bu dosyaları da diğerleri gibi 644 yapmış olacaktır.
wp-config.php Neden Daha Sıkı Tutulur?
wp-config.php dosyası WordPress kurulumunun en hassas dosyasıdır, çünkü veritabanı kullanıcı adı ve şifresi bu dosyada düz metin olarak saklanır. Bu yüzden Codex, diğer dosyalardan farklı olarak bu dosya için 644 yerine 440 ya da hatta 400 izni önerir.
440 izni dosyayı yalnızca sahibi ve grup üyeleri için okunabilir yapar, diğerlerinin okuma hakkını tamamen kapatır. 400 izni ise bir adım daha ileri giderek dosyayı yalnızca sahibi için okunabilir hale getirir. Bu sıkılaştırma sızıntı riskini azaltır — tabii web sunucusu prosesinin dosyanın sahibi veya doğru grubun üyesi olması koşuluyla; aksi halde WordPress veritabanına bağlanamaz ve site çalışmaz.
chmod 440 /path/to/wordpress/wp-config.php
Bu tek satırlık komut, dosyanın diğer 644 dosyalardan ayrı tutulması gerektiğinin en somut hâlidir: toplu chmod komutundan hemen sonra, yalnızca bu dosyaya özel olarak ayrıca çalıştırılmalıdır.
777 Tehlikesi ve "Çalışmıyorsa 777 Yapın" Tavsiyesi
Paylaşımlı hosting ortamında bu, aynı fiziksel sunucudaki başka bir hesabın — ya da güvenliği aşılmış herhangi bir sürecin — WordPress dosyalarına doğrudan kötü amaçlı kod enjekte edebilmesi anlamına gelir. 777 izni verildiğinde dosya sahipliği artık bir koruma sağlamaz; sunucudaki herhangi bir kullanıcı dosyayı okuyabilir, yazabilir ve çalıştırabilir. Bir dosya yükleme betiği ya da tema dosyası bu şekilde açık bırakıldığında, kötü amaçlı kod doğrudan o dosyanın üzerine yazılabilir ve site sahibi bunu fark etmeden uzun süre çalışır durumda kalabilir.
Örnek: Yanlış ve Doğru Yaklaşım
Bir eklenti kurulumu sırasında "dizine yazılamıyor" hatası alan bir yönetici, çoğu zaman ilk çözüm olarak ilgili dizini 777 yapar ve hata kaybolduğu için sorunu "çözülmüş" sayar. Oysa aynı hata, dizinin sahipliğinin web sunucusu kullanıcısına ait olmamasından kaynaklanıyor olabilir. Doğru yaklaşım, dizni 755'te tutup sahipliğini (owner/group) web sunucusu prosesinin kullanıcısıyla eşleştirmektir; bu şekilde hem eklenti yazabilir hem de dizin sunucudaki diğer kullanıcılara kapalı kalır.
Doğru Çözüm: İzin Gevşetme Değil, Doğru Sahiplik
"İzin hatası" genellikle izinlerin çok sıkı olmasından değil, dosya sahipliğinin (owner/group) web sunucusu kullanıcısıyla eşleşmemesinden kaynaklanır. Doğru çözüm neredeyse her zaman izinleri 777'ye gevşetmek değil, dosyaların sahipliğini web sunucusu prosesinin çalıştığı kullanıcıyla (ör. www-data, apache) doğru şekilde eşleştirmektir.
Bunun tipik bir örneği wp-content/uploads/ dizinidir. Bu dizinin WordPress tarafından medya yüklemeleri için yazılabilir kalması gerekir; ancak bu, izni 777'ye gevşeterek değil, dizinin sahipliğinin (veya grubunun) web sunucusu kullanıcısına ait olmasını sağlayarak, standart 755 izniyle güvenli biçimde elde edilir. Aynı mantık, eklentilerin önbellek veya günlük (log) dosyası yazdığı diğer dizinler için de geçerlidir: çözüm izni gevşetmek değil, sahipliği doğru kullanıcıya vermektir.
- Dizinler her zaman
755, dosyalar her zaman644olmalı. - wp-config.php için
440veya400tercih edilmeli. - wp-content/uploads/ dahil hiçbir dizin
777yapılmamalı; yazılabilirlik sahiplik ile sağlanmalı. - İzin hatası alındığında önce dosya sahipliği (owner/group) kontrol edilmeli, izin gevşetmek son çare olmamalı.
Bu izinleri doğru sırayla, doğru dosyalara uygulamak birkaç komuttan ibarettir; ancak hangi dosyanın hangi izni alması gerektiğini ezbere bilmek yerine hazır bir referansa bakmak, özellikle wp-config.php gibi istisnaları atlamamak açısından daha güvenlidir.
Codex'in önerdiği tüm izin değerlerini ve kopyalayıp yapıştırabileceğiniz hazır chmod komutlarını tek sayfada bulun.