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-स्वामित्वको डाइरेक्टरी पहिले नै विशेषाधिकार छोडिसकेको डेमनलाई पूर्ण रूपमा देखिन्छ, र तैपनि त्यसलाई लेख्न सकिँदैन। त्यसपछि त्रुटि अनुमतिको समस्या भनी पढिन्छ, जबकि मार्ग ठ्याक्कै त्यहीँ छ जहाँ तपाईंले अपेक्षा गर्नुभएको थियो। डाइरेक्टरीको मालिकलाई हुकले बताउने पहिचानसँग तुलना गर्नुहोस्। ती फरक भए मोड कहिल्यै प्रश्न थिएन।

स्वामित्व बदल्नु अघि हुक वास्तवमा कुन पहिचानमा चल्छ जाँच्नुहोस्। डाइरेक्टरी सुधार्न सेवाको कार्यान्वयन प्रयोगकर्ता बदल्दा अन्यत्र यन्त्र पहुँच र सञ्जाल विशेषाधिकार बदलिन सक्छन्, जुन सानो समस्याका लागि ठूलो मूल्य हो।

पूरै हस्तान्तरण प्रमाणित गर्नुहोस्

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

स्थायी अवस्था आयु मिल्ने ठाउँमा हुनुपर्छ, किनकि रनटाइम डाइरेक्टरी हराउनकै लागि बनेको हो। स्थान सुविधाअनुसार नभई आयुअनुसार छान्नुहोस्। त्यो बानीले यही अन्वेषणको अर्को संस्करण रोक्छ।