PrivateTmp: hook dosyayı yazdı, ama nereye gitti?
Özel bir geçici ad alanı dosyayı silmek yerine gizler. Birimi değiştirmeden önce süreç kökünü denetleyin, ardından paylaşılan verilere gerçek bir yol verin.
Hook’lar başarı bildirir, ama aynı yol bir shell’den bakınca hâlâ boş görünür. Her iki ifade aynı anda doğru olabilir, çünkü bir systemd hizmeti kendi mount ad alanında özel bir geçici dizinle yaşayabilir. Bu anlaşıldığında, ilginç soru yazmanın baştan başarılı olup olmadığıdır.
İki geçici dizin, tek yol
Yalıtım ayarı birime geçici dizinlerin özel bir görünümünü verir, onları salt okunur yapmak yerine. Birim dışındaki süreçler orada ne yazdığını göremez ve bıraktığı her şey birim durunca atılır. Bu yüzden hook’un yazdırdığı yol ile bir shell’den denetlenen yol aynı adlı farklı nesnelere işaret edebilir.
Bu bir görünürlük sorunudur ve veri kaybı sorunu gibi görünür. Hiçbir şey silinmedi, çünkü dosya yalnızca shell’in üye olmadığı bir ad alanında duruyor. Aynı komut birimin içinde çalıştırıldığında farklı davranır ve tartışmayı genellikle çözen gözlem budur. Yazma hakkında bir sonuca varmadan önce birimin ayarlarını okuyun.
Görünmeyeni yazılamazdan ayırın
Başarılı bir yazma ve başarısız bir açma farklı kanıtlar üretir ve bu ayrım onarımı belirler. Hook dosyanın oluşturulduğunu söylüyor ama dışarıdaki bir okuyucu onu bulamıyorsa, bir ad alanı sorununuz var. Eğer hook bir izin hatası veya başarısız açma bildirirse, dosya hiç yazılmamıştır ve ad alanındaki hiçbir değişiklik yardımcı olmaz.
systemctl show [email protected] -p PrivateTmp -p User -p Group -p RuntimeDirectory
systemctl show [email protected] -p MainPID --value
sudo ls -l /proc/PID/root/tmp/client-stateSüreç kökü yolu hizmetin kendi dosya sistemi görünümünü açığa çıkarır; süreç hâlâ çalışırken bu süreç üzerindeki izin denetimlerine tabidir. Birimin günlüğünü aynı oturumda okuyun, çünkü biri nedeni zaten belirlediğinde yazma hatası ile eksik dosya kolayca karıştırılır.
Paylaşılan verilere açık bir konum verin
Yalnızca hizmetin ihtiyaç duyduğu veriler özel geçici dizinine aittir. Başka bir sürecin okuması gereken veriler, ikisi için tanımlanmış bir yol gerektirir; sahibi, kipi ve son kullanma tarihi belirtilmiş olarak. Birimi düzenlemeden önce iki durumdan hangisine sahip olduğunuza karar verin. Bu olayların çoğu özel bir dosyanın paylaşılan dosya gibi ele alınmasından kaynaklanır.
[Service]
RuntimeDirectory=openvpn-hook-office
RuntimeDirectoryMode=0750Bir çalışma zamanı dizini klasörü sistemin çalışma zamanı alanının altına yerleştirir, birimin yapılandırılmış kullanıcısı ve grubu için oluşturur ve birim durunca kaldırır. Paketin birimi bozulmasın diye drop-in üzerinden ekleyin, ardından yöneticiyi yeniden yükleyin ve o örneği yeniden başlatın; istemcilerinin yeniden bağlanacağını kabul ederek.
Kurulu birimin zaten gerektirdiği her çalışma zamanı dizinini koruyun. Listeye eklemek yerine onu değiştirmek, değişiklikle kimsenin ilişkilendirmediği ilgisiz bir özelliği bozmanın yaygın bir yoludur.
İki ayrıcalık katmanı anlaşamayabilir
Hizmet yöneticisi dizini birimin yapılandırılmış kullanıcısı için oluşturur; VPN servisi ise bir bağlantı hook’u çalıştırmadan önce ayrı olarak kendi hesabına inebilir. Bunlar farklı katmanlardır ve farklı kimlikler adlandırabilirler.
Root’a ait, kısıtlayıcı kipli bir dizin, ayrıcalıklardan çoktan vazgeçmiş bir servis için tamamen görünürdür ve yine de onun tarafından yazılamaz. Hata o zaman izin sorunu olarak okunur, oysa yol tam beklediğiniz yerde vardır. Dizinin sahibini hook’un bildirdiği kimlikle karşılaştırın. Farklı olduklarında kip hiçbir zaman soru değildi.
Sahiplik değiştirmeden önce hook’un gerçekte hangi kimlikle çalıştığını denetleyin. Bir dizini onarmak için hizmetin çalıştırma kullanıcısını değiştirmek başka yerlerde aygıt erişimini ve ağ ayrıcalıklarını değiştirebilir; bu küçük bir sorun için yüksek bir bedeldir.
Tüm devri doğrulayın
Dört şeyi aynı anda doğrulayın: hook gerçek kimliğiyle yazar, amaçlanan okuyucu dosyayı kullanabilir, ilgisiz kullanıcılar kullanamaz ve birimin durdurulması tasarlandığı gibi temizler. Ana makinenin paylaşılan geçici dizininde bir dosyanın görünmesi bir gereklilik değildir ve genellikle takasın hiçbir zaman kendi yolunu almadığının işaretidir. Okuyucuyu yeniden başlatmadan sonra sınayın, yalnızca ilk çalıştırma sırasında değil. Temizleme davranışı tasarımın parçasıdır, bu yüzden varsaymak yerine gözlemleyin.
Kalıcı durum, yaşam süresi uygun bir yere aittir, çünkü çalışma zamanı dizini yok olmak için tasarlanmıştır. Konumu kolaylığa göre değil yaşam süresine göre seçin. Bu alışkanlık aynı incelemenin sonraki sürümünü önler.