İzinler servisimi bozdu: işe yarayan düzeltme sırası
Güncelleme
Permission denied servis arızaları sabit sırayla: önce tekrar üret, kullanıcıları adlandır, sonra en dar onarımı uygula.
Permission denied bir Linux makinedeki en dürüst hatadır. Olanı tam söyler: bu kullanıcı o dosyayı istedi, mod bitleri hayır dedi. Çoğu mühendis yine de izinleri hata kaybolana kadar genişleterek düzeltir; bir kez çalışır, makineyi kalıcı zayıflatır.
Düzeltme sırası
Servis kullanıcısı tarafından tekrar üret. Başarısız okumayı servis hesabıyla çalıştır ya da yetki geçişi yoksa id ve ls -l çıktısından çıkar. Hiçbir şeye dokunmadan red satırının birebirini notuna kopyala.
İki kullanıcıyı adlandır. Okuyucu (süreç kullanıcısı) ve sahip (dosya sahibi). Sonra geçerli izin sütununu adlandır: user, group ya da other. Bu adımdan önce onarımı tahmin etmek makineleri herkesin okuduğu hale getirir.
En dar onarımı uygula. İki aday çoğu durumu kapatır: okuyucuyu dosyanın grubuna alıp 640 yap, ya da sahipliği okuyucuya geçirip 600 yap. Birini seç, diğerinin neden daha kötü olduğunu bir cümleyle yaz, sonra servis kullanıcısı olarak doğrula.
Çalışılmış örnek: kimsenin okuyamadığı kurgusal yapılandırma
Aşağıdaki bağlam kurgusaldır. Kurgusal deploysvc kullanıcısı /srv/app/config.env dosyasından yapılandırma sunar; dosya bir insan hesabına aittir, mod 600. Dizüstü yenilemesinden sonra dosya yeniden kopyalanır, sahip değişir, servis permission denied ile kırılır.
Servis kullanıcısıyla tekrar üretim red satırını dosyada gösterir. İki kullanıcı deploysvc (okuyucu) ve insan hesabı (sahip); geçerli sütun yalnızca user, group ve other kapalı. Onarım: appconfig grubu kur, deploysvc kullanıcısını ekle, dosyayı appconfig grubuna 640 yap. deploysvc olarak doğrulama okur; alakasız kullanıcı olarak doğrulama hâlâ reddedilir. Dar, kanıtlı, bitti.
Karar tablosu: iki yaygın onarım
| Durum | Onarım | Neden |
|---|---|---|
| Dosyayı birkaç servis kullanıcısı paylaşır | Grup okuma (chgrp + 640) | Tek grup değişimi tüm okuyucuları kapatır, kontrol sahipte kalır |
| Tek okuyucu, hassas içerik | Sahiplik değişimi (chown + 600) | Yönetilecek grup yok, başkası bir şey kazanmaz |
| Okuyucu kümesi bilinmiyor | Önce dur ve öğren | Kör genişletme sır sızıntısıdır |
Kontrol listesi: savunulabilir bir izin düzeltmesi
- Red satırının birebiri notunda.
- Okuyucu, sahip ve izin sütunu adlandırılmış.
- Reddedilen alternatifin bir yazılı gerekçesi var.
- Servis kullanıcısıyla doğrulandı, alakasız kullanıcıyla hâlâ reddediliyor.
İlgili okuma
- Tarayıcıda ücretsiz pratik yap: İzinlerin Bozduğu Servisi Düzelt.
- DevOps Foundations izinleri ait olduğu Modül 1'e koyar.
Net yanıtlar
Sık sorulan sorular
Neden chmod 777 yapıp geçmiyoruz?
Beş dakikalık teşhisi kalıcı açık kapıyla takas edersin. Sonraki denetim, sonraki olay ya da sonraki ekip arkadaşı öder.
Önce chown mu chgrp mi?
Hiçbiri. Önce tekrar üret ve iki kullanıcıyı adlandır; grup okuma ile sahiplik değişimi arasındaki seçim bundan sonra gelir.
Düzeltmeyi nasıl kanıtlarım?
Root olarak değil, servis kullanıcısı olarak doğrula. Servis hesabı okuyabiliyor ve başkası erişim kazanmadıysa iş bitmiştir.