Dosyalar, İzinler ve Sahiplik

Neden önemli

Dağıtım yeşil biter, servis açılmaz ve log, dağıtımın kendisinin oluşturduğu bir dosyada "permission denied" der. Nöbetçi genç mühendisin aldığı en yaygın ilk çağrılardandır ve neredeyse her zaman iki olgudan oluşur: süreç bir kullanıcı olarak çalışır, dosya başka birine aittir. On dakikalık izin okuryazarlığı bir saatlik tahminin yerini tutar; üstelik üretimde tahmin yürütmek genelde hata susana kadar izinleri genişletmek demektir. Bu, hatayı susturur ve kapıyı açar.

Kavramlar

Her dosya üç sorunun cevabını taşır: sahibi kim (kullanıcı), hangi gruba bağlı (grup) ve üç sınıfın her biri ne yapabilir (kullanıcı, grup, diğer). Üç eylem read (4), write (2) ve execute (1) sayılarıdır; tanıdık 755 yalnızca bu üç toplamın yan yana yazılmışıdır. Dizinler aynı bitleri farklı anlamla kullanır: read isimleri listeler, write isim oluşturur ve siler, execute içeriğe ulaşmayı sağlar. 644 modlu bir dizin cam kapılı kilitli odadır: isimleri görürsün ama içeri asla giremezsin.

Sahiplik hangi sütunun sana uygulanacağına karar verir. Bir süreç tam olarak bir kullanıcı ve bir birincil grupla çalışır; çekirdek önce kullanıcı sütununa, sonra gruba, sonra diğere bakar ve ilk eşleşmede durur. Ek gruplar grup kontrolünü genişletir; bu yüzden dağıtım kullanıcısını servis grubuna eklemek genelde doğru onarımdır: süreci herkese açmak yerine grup sütununa taşır.

Tabloyu üç özel bit tamamlar. Setuid (4) ve setgid (2) programı dosya sahibinin veya grubunun haklarıyla çalıştırır; nadirdir, güçlüdür, icat etmek yerine denetlenir. /tmp gibi bir dizindeki sticky bit (1) herkesin dosya oluşturmasına izin verir ama herkes yalnızca kendi dosyasını siler. Varsayılan izinler umask bitlerinin istenen moddan kaldırılmasıyla bulunur (istenen & ~umask, varsayılan ACL yokken): dosyalar 666, dizinler 777 ister; 022 umask 644 dosya ve 755 dizin üretir (örneğin 0666 & ~0022 = 0644); yeni dosyalar okunabilir ama asla çalıştırılabilir doğmaz.

Uygulamalı örnek

Bir servis birimi svc-app kullanıcısıyla çalışır ve açılışta düşer:

$ ls -l /srv/app/config.yaml -rw------- 1 deploy deploy 312 Oct 2 11:40 /srv/app/config.yaml $ sudo -u svc-app head -1 /srv/app/config.yaml head: cannot open '/srv/app/config.yaml' for reading: Permission denied

Bu çıktının beklenen okuması: dosya 600, sahibi deploy kullanıcısı, grubu deploy. Süreç kullanıcısı svc-app ikisine de uymaz, other sütununa düşer ve orada hiçbir hak yoktur. İki onarım savunulabilir. Dosya dağıtım hattına aitse grubu değiştirip grup sütununu aç: chgrp svc-app config.yaml ve chmod 640 config.yaml. Konfigürasyon servisin kendisine aitse sahipliği devret: chown svc-app:svc-app config.yaml ve 600 modda tut. Doğrulamayı kendin olarak veya root olarak değil, servis kullanıcısı gibi okuma komutuyla yap. Root standart dosya izni kontrollerini atlar; root olarak başarılı okuma, servis kullanıcısının okuyabildiğini kanıtlamaz.

Yaygın yanlış hamle

chmod -R 777 /srv/app hatayı yok eder ve başlı başına bir olay olarak ele alınmalıdır. Dizindeki uygulama koduna, konfigürasyona ve tutulan her gizli değere her yerel kullanıcıya okuma, yazma ve çalıştırma verir. Sürüm kontrolü notu: Git tam Unix sahipliğini ve her mod bitini sürümlemez; normal dosyalarda temel ayrım çalıştırılabilirliktir, bu yüzden diskteki 777 bir sonraki klonda birebir 777 olarak geri gelmez; ama fazla geniş bitler düzeltilene kadar kurulu her makinede canlı kalır. Diğer klasik chown -R root çekip servisi root çalıştırmaktır: ele geçen servis artık tüm makineye sahiptir. Bir izin hatası seni ikisine de iterse dur ve ilgili iki kullanıcıyı adlandır (süreç kullanıcısı, dosya sahibi). Onarım her zaman bu ikisi arasındaki ilişkidir, asla genel bir açılış değildir.

Lab ve sonraki adım

Bu modüldeki L01 labı aynı arızayı birebir canlandırır; 640 üzerine çıkmadan onarırsın. Sırada 2. ders var: dosyaların arkasına bir süreç koyar; kullanıcılar, PID'ler, sinyaller ve onları başlatan servis yöneticisi.