OpenVPN हुकले आफ्नो स्क्रिप्टको छेउको फाइल किन भेट्टाउन सक्दैन

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

अनुमतिअघि बाटो जाँच्नुहोस्, किनकि गलत फाइलमा अनुमतिको त्रुटि तैपनि गलत फाइल नै हो।

सापेक्ष बाटो फाइलको नभई प्रक्रियाको सापेक्ष हल हुन्छ

जब स्क्रिप्टले open("policy.json") लाई कल गर्छ, कर्नेलले त्यो नाम प्रक्रियाको वर्तमान कार्यशील निर्देशिकाको सापेक्ष हल गर्छ। स्क्रिप्टको आफ्नै स्थानबाट केही पनि त्यो खोजीमा सहभागी हुँदैन। OpenVPN आफैले छान्ने निर्देशिकाबाट हुक सुरु गर्छ, र cd विकल्पले त्यसलाई बदल्न सक्छ, त्यसैले आफ्नै फोल्डरबाट हातले जाँचिएको स्क्रिप्ट डेमनले चलाउँदा फरक व्यवहार गर्छ। हातको परीक्षण उत्तीर्ण हुन्छ, सेवा चलाउनु असफल हुन्छ, र लगको लाइनले हराएको नाम मात्र उल्लेख गर्छ।

Python ले स्क्रिप्टको स्थान __file__ को रूपमा खोल्छ, र त्यही एङ्करिङ सम्भव बनाउँछ। Path(__file__).resolve().parent / "policy.json" प्रक्रियाबाट नभई फाइलबाट बाटो बनाउँछ। त्यो एउटा लाइनले विशेषाधिकारमा केही नबदली कार्यशील निर्देशिकाको निर्भरता हटाउँछ।

बाटो जानाजान एङ्कर गर्नुहोस्, त्यसपछि resolve ले के गर्छ जाँच्नुहोस्

resolve() प्रतीकात्मक लिङ्कहरू पछ्याउँछ, त्यसैले हुकलाई त्यसको ठाउँमा लिङ्क गर्ने स्थापना लिङ्कको लक्ष्यमा एङ्कर हुन्छ, लिङ्क राख्ने निर्देशिकामा होइन। संस्करणयुक्त तैनातीका लागि सामान्यतया यही चाहिन्छ, र प्रतीकात्मक लिङ्कको छेउमा डेटा अपेक्षा गर्ने लेआउटका लागि यो गलत हो। तैनातीले कुन अर्थ लिन्छ निर्णय गर्नुहोस्, र उत्पादनमा भिन्नता पत्ता लगाउनुको सट्टा त्यही अनुसार कोड लेख्नुहोस्। Path(__file__).parent बिना resolve() लिङ्कको आफ्नै निर्देशिका राख्छ।

यदि डेटा कार्यक्रमको नभई इन्स्टेन्सको हो भने कन्फिगरेसनबाट निरपेक्ष बाटो लिनुहोस्। स्थान हार्डकोड गर्नुले हुकलाई एउटै होस्ट लेआउटसँग बाँध्छ।

चार सीमाहरू क्रमैसँग पार गर्नुहोस्

कार्यशील निर्देशिकाबाट सुरु गर्नुहोस्: युनिटको WorkingDirectory, OpenVPN को cd विकल्प र exec अघि निर्देशिका बदल्ने कुनै पनि र्यापर तुलना गर्नुहोस्। त्यसपछि हल भएको स्थान पुष्टि गर्नुहोस्, किनकि अर्को तैनातीको समान नामको फाइलले खोजीलाई जवाफ दिएर त्रुटि लुकाउन सक्छ। त्यसपछि फाइलसिस्टमको दृश्य आउँछ: chroot वा सेवाको माउन्ट नेमस्पेसले होस्टको निरपेक्ष बाटोलाई सजिलै अनुपस्थित बनाउन सक्छ। अन्तमा पहुँच पहिचान, जो दृश्यताबाट छुट्टै प्रश्न हो।

ProtectHome र PrivateTmp फरक फरक स्थान लुकाउँछन्, र होस्टबाट लिइएको निर्देशिका सूचीमा दुवैमध्ये कुनै देखिँदैन। शेलमा root का लागि रहेको बाटो युनिटको नेमस्पेसभित्र अदृश्य हुन सक्छ, र त्यसैले सेवाबाहिर त्यही आदेश जाँच्नु धेरै थोरै प्रमाणित गर्छ।

सेवा विस्तार नगरी खोजी सुधार्नुहोस्

बाटो एङ्कर गर्नुले पहिलो सीमा मात्र हल गर्छ। यसले सेवाले लुकाएको निर्देशिका खोल्दैन, र विशेषाधिकार नभएको खातालाई root का लागि मात्र भएको फाइलमा पहुँच दिँदैन। script-security बढाउनुले OpenVPN ले कुन स्क्रिप्ट चलाउने भन्ने बदल्छ; सापेक्ष नाम कहाँ हल हुन्छ भन्नेमा यसको कुनै प्रभाव छैन। पूरै सेवाको कार्यशील निर्देशिका बदल्नु समस्याभन्दा फराकिलो हुन्छ, किनकि अन्य प्रत्येक सापेक्ष प्रमाणपत्र, लग वा सहायक बाटो त्यसैसँग सर्छ।

साँघुरो सुधार रोज्नुहोस्: स्क्रिप्टमा निर्धारक बाटो, इन्स्टेन्स डेटाका लागि स्पष्ट कन्फिगरेसन मान, र हुक वास्तवमा जुन खातामुनि चल्छ त्यससँग मिल्ने फाइल स्वामित्व।

सीमाको नाम लिने प्रमाण रेकर्ड गर्नुहोस्

उपयोगी असफलता प्रतिवेदनमा तीन कुरा हुन्छन्: हुकले प्रयास गरेको ठ्याक्कै बाटो, त्यो उत्पन्न गर्ने वातावरण, र कुन सीमाले अस्वीकार गर्यो। फाइलको सामग्री नपोखी हल भएको बाटो र अपवाद प्रिन्ट गर्नुहोस्। यो त्रिकले गलत एङ्करलाई लुकेको माउन्टबाट र अनुमति अस्वीकारबाट छुट्याउँछ, र ती तीन फरक सुधार हुन्।

root ले टर्मिनलबाट फाइल पढ्न सक्छ भन्ने दाबीले ती प्रश्नमध्ये एउटाको मात्र जवाफ दिन्छ, बाँकी कुनैको दिँदैन। यसको सट्टा सेवाकै सन्दर्भबाट जाँच्नुहोस्।