Bir OpenVPN kancası betiğinin yanındaki dosyayı neden bulamaz

Hatasız çalışıp yine de eksik dosya bildiren kancalar genellikle yanlış yere bakıyordur, işlerinde başarısız olmuyordur. Bir betikteki göreli yollar sürecin çalışma dizinine göre çözülür ve bir hizmet sizin seçmediğiniz bir çalışma diziniyle başlar. Betiğin yanındaki dosya ile sürecin açtığı dosya ancak bir şey onları sabitlediğinde aynı şeydir. Bu boşluk, yanlışlıkla izin sorunu diye okunan kanca arızalarının büyük bölümünü açıklar.

Yolu izinlerden önce denetleyin, çünkü yanlış dosyadaki izin hatası yine yanlış dosyadır.

Göreli yol dosyaya değil sürece göre çözülür

Bir betik open("policy.json") çağırdığında, çekirdek adı sürecin geçerli çalışma dizinine göre çözer. Betiğin kendi konumundan hiçbir şey o aramaya katılmaz. OpenVPN kancaları kendi seçtiği bir dizinden başlatır ve cd seçeneği bunu değiştirebilir, bu yüzden kendi klasöründen elle test edilen bir betik, daemon onu çalıştırdığında farklı davranır. Elle test geçer, hizmet çalıştırması başarısız olur ve günlük satırı yalnızca eksik adı anar.

Python betiğin konumunu __file__ olarak açığa çıkarır ve sabitlemeyi mümkün kılan da budur. Path(__file__).resolve().parent / "policy.json" yolu süreçten değil dosyadan kurar. O tek satır, ayrıcalıklarda hiçbir şeyi değiştirmeden çalışma dizini bağımlılığını kaldırır.

Yolu bilerek sabitleyin, sonra resolve'un ne yaptığını denetleyin

resolve() sembolik bağlantıları izler, bu yüzden kancayı yerine bağlayan bir kurulum bağlantının hedefinde sabitlenir, bağlantıyı tutan dizinde değil. Sürümlenmiş bir dağıtım için genellikle istenen budur ve sembolik bağlantının yanında veri bekleyen bir düzen için yanlıştır. Dağıtımın ne demek istediğine karar verin ve farkı üretimde keşfetmek yerine kodu ona göre yazın. Path(__file__).parent olmadan resolve() bağlantının kendi dizinini korur.

Veri programın değil örneğin ise yapılandırmadan mutlak bir yol alın. Bir konumu sabit kodlamak kancayı tek bir ana makine düzenine bağlar.

Dört sınırı sırayla geçin

Çalışma diziniyle başlayın: birimin WorkingDirectory, OpenVPN'in cd seçeneği ve exec öncesi dizin değiştiren her sarmalayıcıyla karşılaştırın. Ardından çözülen konumu doğrulayın, çünkü başka bir dağıtımdaki benzer adlı bir dosya aramaya yanıt verip hatayı gizleyebilir. Sırada dosya sistemi görünümü var: bir chroot veya hizmetin mount ad alanı, ana makinenin mutlak yolunu basitçe yok edebilir. Son olarak erişim kimliği, bu görünürlükten ayrı bir sorudur.

ProtectHome ve PrivateTmp farklı konumları gizler ve ikisi de ana makineden alınan bir dizin listesinde görünmez. Kabukta root için var olan bir yol, birimin ad alanı içinde görünmez olabilir ve bu yüzden aynı komutu hizmet dışında denemek çok az şey kanıtlar.

Aramayı hizmeti genişletmeden düzeltin

Yolu sabitlemek yalnızca ilk sınırı çözer. Hizmetin gizlediği bir dizini açığa çıkarmaz ve ayrıcalığı olmayan bir hesaba yalnızca root için olan bir dosyaya erişim vermez. script-security yükseltmek OpenVPN'in hangi betikleri çalıştıracağını değiştirir; göreli adın nerede çözüldüğü üzerinde hiçbir etkisi yoktur. Tüm hizmet için çalışma dizinini değiştirmek sorundan daha geniştir, çünkü diğer her göreli sertifika, günlük veya yardımcı yolu onunla birlikte taşınır.

Dar düzeltmeyi yeğleyin: betikte belirlenimci bir yol, örnek verisi için açık bir yapılandırma değeri ve kancanın gerçekten altında çalıştığı hesaba uyan dosya sahipliği.

Sınırı adlandıran kanıtları kaydedin

Kullanışlı bir arıza raporu üç şey içerir: kancanın denediği tam yol, onu üreten ortam ve hangi sınırın reddettiği. Çözülen yolu ve istisnayı dosyanın içeriğini dökmeden yazdırın. Bu üçlü, yanlış sabitlemeyi gizli bir mount'tan ve izin reddinden ayırır; bunlar üç farklı düzeltmedir.

root'un dosyayı bir terminalden okuyabildiği iddiası o sorulardan yalnızca birini yanıtlar, diğerlerinin hiçbirini yanıtlamaz. Bunun yerine hizmetin kendi bağlamından test edin.