PrivateTmp: हुक ने फ़ाइल लिखी, तो वह कहाँ गई?

हुक सफलता की सूचना देते हैं, और वही रास्ता शेल से अब भी खाली दिखता है। दोनों कथन एक ही समय में सही हो सकते हैं, क्योंकि एक systemd सेवा अपने ही माउंट नामस्थान में निजी अस्थायी निर्देशिका के साथ रह सकती है। यह समझ आने के बाद दिलचस्प सवाल यह है कि लिखावट आख़िरकार सफल हुई या नहीं।

दो अस्थायी निर्देशिकाएँ, एक ही रास्ता

अलगाव की सेटिंग यूनिट को अस्थायी निर्देशिकाओं का निजी दृश्य देती है, उन्हें केवल-पढ़ने योग्य बनाने के बजाय। यूनिट के बाहर की प्रक्रियाएँ यह नहीं देख सकतीं कि वह वहाँ क्या लिखती है, और यूनिट रुकने पर उसके पीछे छूटा सब कुछ छोड़ दिया जाता है। इसलिए हुक द्वारा छापा गया रास्ता और शेल से जाँचा गया रास्ता एक ही नाम की अलग-अलग वस्तुओं की ओर संकेत कर सकते हैं।

यह दृश्यता की समस्या है, और यह डेटा खोने की समस्या जैसी दिखती है। कुछ भी मिटाया नहीं गया, क्योंकि फ़ाइल बस ऐसे नामस्थान में है जिसका सदस्य शेल नहीं है। यही आदेश यूनिट के भीतर चलाने पर अलग व्यवहार करता है, और यही अवलोकन आमतौर पर विवाद तय करता है। लिखावट के बारे में कोई निष्कर्ष निकालने से पहले यूनिट की सेटिंग्स पढ़ें।

अदृश्य को अलिखनीय से अलग करें

सफल लिखावट और असफल खोलना अलग सबूत देते हैं, और यही अंतर मरम्मत तय करता है। अगर हुक कहता है कि फ़ाइल बन गई है पर बाहरी पाठक उसे नहीं ढूँढ पाता, तो आपके पास नामस्थान का सवाल है। अगर हुक अनुमति त्रुटि या असफल खोलने की सूचना देता है, तो फ़ाइल कभी लिखी ही नहीं गई और नामस्थान का कोई बदलाव मदद नहीं करेगा।

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-state

प्रक्रिया-जड़ का रास्ता सेवा का अपना फ़ाइलतंत्र दृश्य दिखाता है, जो उस प्रक्रिया पर अनुमति जाँच के अधीन है जब तक वह चल रही हो। उसी सत्र में यूनिट का जर्नल पढ़ें, क्योंकि किसी के पहले ही कारण तय कर लेने पर लिखावट की त्रुटि और गुम फ़ाइल आसानी से मिला दी जाती है।

साझा डेटा को स्पष्ट स्थान दें

जो डेटा केवल सेवा को चाहिए वह उसकी निजी अस्थायी निर्देशिका में ही रहता है। जो डेटा किसी दूसरी प्रक्रिया को पढ़ना है उसके लिए दोनों के लिए परिभाषित रास्ता चाहिए, जिसमें मालिक, मोड और समाप्ति बताई गई हो। यूनिट संपादित करने से पहले तय करें कि आपके पास दोनों में से कौन-सा मामला है। इनमें से अधिकांश घटनाएँ निजी फ़ाइल को साझा फ़ाइल मानने से आती हैं।

[Service]
RuntimeDirectory=openvpn-hook-office
RuntimeDirectoryMode=0750

रनटाइम निर्देशिका फ़ोल्डर को सिस्टम के रनटाइम क्षेत्र के अंतर्गत रखती है, यूनिट के कॉन्फ़िगर किए गए उपयोगकर्ता और समूह के लिए उसे बनाती है और यूनिट रुकने पर उसे हटा देती है। पैकेज की यूनिट सुरक्षित रहे इसलिए इसे drop-in के ज़रिए जोड़ें, फिर प्रबंधक को दोबारा लोड करें और उस इंस्टेंस को फिर से शुरू करें, यह स्वीकार करते हुए कि उसके क्लाइंट फिर जुड़ेंगे।

इंस्टॉल की गई यूनिट जो भी रनटाइम निर्देशिका पहले से माँगती है उसे रखें। सूची में जोड़ने के बजाय उसे बदल देना किसी असंबंधित सुविधा को तोड़ने का आम तरीका है, जिसे कोई बदलाव से नहीं जोड़ता।

विशेषाधिकार की दो परतें असहमत हो सकती हैं

सेवा प्रबंधक यूनिट के कॉन्फ़िगर किए गए उपयोगकर्ता के लिए निर्देशिका बनाता है, जबकि VPN डेमॉन कनेक्शन हुक चलाने से पहले अलग से अपने खाते में उतर सकता है। ये अलग परतें हैं, और ये अलग पहचान बता सकती हैं।

प्रतिबंधक मोड वाली root की निर्देशिका उस डेमॉन के लिए पूरी तरह दृश्य है जो पहले ही विशेषाधिकार छोड़ चुका है, और फिर भी उसके लिए अलिखनीय है। तब त्रुटि अनुमति की समस्या के रूप में पढ़ी जाती है, जबकि रास्ता ठीक वहीं मौजूद है जहाँ आपने अपेक्षा की थी। निर्देशिका के मालिक की तुलना हुक द्वारा बताई गई पहचान से करें। जब वे अलग हों, तो मोड कभी सवाल नहीं था।

मालिकाना बदलने से पहले जाँचें कि हुक वास्तव में किस पहचान के अधीन चलता है। निर्देशिका ठीक करने के लिए सेवा का निष्पादन उपयोगकर्ता बदलने से कहीं और उपकरण पहुँच और नेटवर्क विशेषाधिकार बदल सकते हैं, जो छोटी समस्या के लिए बड़ी कीमत है।

पूरा हस्तांतरण सत्यापित करें

एक साथ चार चीज़ें पुष्ट करें: हुक अपनी असली पहचान के अधीन लिखता है, इच्छित पाठक फ़ाइल का उपयोग कर सकता है, असंबंधित उपयोगकर्ता नहीं कर सकते, और यूनिट रोकने पर डिज़ाइन के अनुसार सफ़ाई होती है। होस्ट की साझा अस्थायी निर्देशिका में फ़ाइल दिखना कोई अनिवार्यता नहीं है, और यह आमतौर पर संकेत है कि अदला-बदली को कभी अपना रास्ता नहीं मिला। पुनःआरंभ के बाद पाठक की जाँच करें, केवल पहली बार चलाने के दौरान नहीं। सफ़ाई का व्यवहार डिज़ाइन का हिस्सा है, इसलिए मानने के बजाय उसे देखें।

स्थायी स्थिति ऐसी जगह की होनी चाहिए जहाँ आयु मेल खाए, क्योंकि रनटाइम निर्देशिका गायब होने के लिए ही बनी है। स्थान सुविधा के बजाय आयु के अनुसार चुनें। यह आदत इसी जाँच का अगला संस्करण रोकती है।