Linux Permission Sistemi: chmod, chown ve rwx Mantığı

Bir API yüklenen dosyayı kaydedemiyor ve logda “Permission denied” yazıyor. İnternette bulunan chmod -R 777 komutunu çalıştırmak hatayı görünmez yapabilir; fakat hangi kullanıcının neye erişmesi gerektiği sorusunu cevaplamaz. Sağlam bir çözüm, süreç kimliğini, dizin yolunu ve gerekli işlemi birlikte değerlendirir.

İzin satırını okumak

ls -l report.txt
stat report.txt
id

Örneğin -rw-r----- çıktısındaki ilk karakter dosya türünü, sonraki üçlüler sırasıyla sahibi, grubu ve diğer kullanıcıların izinlerini gösterir. r okuma, w yazma, x çalıştırma anlamına gelir. Bir süreç dosyanın sahibi ise owner bitleri değerlendirilir; uygun grup üyeliği varsa grup sınıfı, aksi durumda diğerleri devreye girer. Klasik model, tüm sınıfların izinlerini toplayarak en geniş sonucu seçmez.

İzin kontrolünü kendi kullanıcı hesabınızla yapmak yeterli olmayabilir. Terminalde dosyaya yazabiliyor olmanız, taskapi kullanıcısıyla çalışan servisin de yazabildiğini göstermez.

Dosya ve dizinde aynı harfler farklı işlemleri anlatır

Normal bir dosyada okuma içeriği okumayı, yazma içeriği değiştirmeyi, çalıştırma ise uygun dosyayı program olarak yürütmeyi kontrol eder.

Dizinde r isimleri listelemeyi, x dizinden geçerek bilinen isimlere erişmeyi, w ise gerekli diğer izinlerle birlikte dizin girdilerini oluşturmayı veya kaldırmayı kontrol eder. Bir dosyayı silmek çoğunlukla dosyanın kendi yazma bitinden çok üst dizinin izinleriyle ilgilidir; sticky bit ve başka mekanizmalar bunu sınırlayabilir. Bu ayrıntıların temeli inode(7) içinde açıklanır.

Bu yüzden yalnızca hedef dosyayı değil bütün yolu inceleyin:

namei -l /var/lib/task-api/uploads/report.txt

Üst dizinlerden birinde geçiş izni yoksa, hedef dosyanın izinleri açık olsa bile erişim başarısız olabilir.

Sayısal ve sembolik gösterim

Her izin üçlüsünde okuma 4, yazma 2, çalıştırma 1 değerini taşır. Örneğin 640; sahip için 6 yani okuma+yazma, grup için 4 yani okuma, diğerleri için 0 demektir.

chmod 640 report.txt
chmod u+x maintenance.sh
chmod g-w report.txt

Sembolik gösterim, yalnızca değiştirmek istediğiniz biti ifade etmek için kullanışlıdır. Sayısal gösterim bütün klasik izin setini açıkça tanımlar. chmod sahipliği değiştirmez; onun işi izin bitleridir. Komutun seçenekleri chmod(1) kılavuzunda bulunur.

Dizinleri ve dosyaları tek bir recursive izin komutuyla aynı moda geçirmek genellikle gereksiz çalıştırma izinleri veya erişilemeyen dizinler üretir. Önce işlem kapsamını belirleyin, ardından dosya türüne göre farklı kurallar uygulayın.

chown: dosyanın sahibi kim?

chown, kullanıcı ve grup sahipliğini değiştirir. Aşağıdaki örnek, var olan taskapi hesabı için yalnızca uygulamanın yazacağı dizini hazırlar:

sudo install -d -o taskapi -g taskapi -m 750 /var/lib/task-api/uploads
sudo -u taskapi test -w /var/lib/task-api/uploads

Uygulamanın koduna ve yapılandırmasına da aynı yazma yetkisini vermek zorunda değilsiniz. Bir yükleme açığı olduğunda uygulamanın kendi executable veya config dosyalarını değiştirememesi, etki alanını daraltır. Sahiplik seçenekleri için chown(1) belgesine bakabilirsiniz.

Paylaşılan grup yaklaşımı kullanılacaksa deployment kullanıcısı ile servis kullanıcısının gerçek grup üyeliklerini kontrol edin. Grup değişikliği, zaten çalışan süreçlerin kimliğine her zaman kendiliğinden yansımaz; yeni oturum veya kontrollü servis yeniden başlatması gerekebilir.

umask, setgid ve ACL neyi değiştirir?

umask, yeni nesne oluşturulurken talep edilen izinlerden belirli bitleri kaldıran maskedir. Mevcut dosyalara geriye dönük uygulanmaz. Örneğin 027 maskesi, tipik 666 tabanlı bir dosyayı 640; 777 tabanlı bir dizini 750 olarak oluşturur. Program daha dar izin talep ederse maske onu genişletmez.

Bir paylaşılan dizindeki setgid biti, yeni girdilerin grup sahipliğinin dizinin grubunu izlemesine yardımcı olabilir. Ancak yeni dosyaların grup tarafından yazılabilir olmasını tek başına garanti etmez; oluşturma modu ve umask da önemlidir.

Klasik owner/group/other modeli yetersizse ACL ile belirli kullanıcı veya gruplara izin verilebilir. getfacl çıktısındaki maskenin etkin izinleri sınırlayabildiğini unutmayın. ACL, yalnızca ls -l bakılarak açıklanamayan erişim davranışlarının bir nedeni olabilir.

Teşhis: genişletmeden önce doğrula

Örnek yükleme hatasında şu sırayla ilerleyin: servisin kullanıcısını bulun, gerçek yazma yolunu belirleyin, üst dizinleri kontrol edin ve işlemi aynı kullanıcıyla deneyin. Ardından dosya sisteminin salt okunur bağlanıp bağlanmadığına bakın. SELinux veya AppArmor gibi ek kontroller de klasik bitler doğru görünse bile erişimi engelleyebilir.

Sorunu çözmek için bütün güvenlik mekanizmalarını kapatmak yerine, reddedilen işlemin hangi katmandan geldiğini belirleyin. Başarılı sonuç yalnızca hatanın kaybolması değildir: servis ihtiyaç duyduğu yere yazabilmeli, gereksiz yerlere yazamamalıdır.