कुंजी से पहले हर निर्देशिका पर खोज अनुमति
0600 मोड होने पर भी कुंजी खुलने से मना कर सकती है, जब कोई जनक निर्देशिका मार्ग को अवरुद्ध करे। कोई भी मोड बदलने से पहले सेवा खाते के रूप में पूरा पथ जाँचें।
0600 मोड और सही स्वामी यह गारंटी नहीं देते कि सेवा कुंजी खोल सके। अनुपस्थित अनुमति आमतौर पर इसके ऊपर की निर्देशिका पर होती है। लिनक्स पथ को एक बार में एक घटक के रूप में हल करता है, और हर चरण को अगले प्रयास से पहले खोज अनुमति चाहिए। पूरा पथ पढ़ें, सूची की अंतिम पंक्ति नहीं।
पढ़ने की अनुमति अंतिम चरण है, एकमात्र नहीं
किसी फ़ाइल को खोलने के लिए कर्नेल को रूट या कार्य निर्देशिका से पथ के हर घटक से गुजरना पड़ता है। खोज अनुमति के बिना निर्देशिका उस यात्रा को अनुमति त्रुटि के साथ रोक देती है। फ़ाइल के अपने मोड को कभी नहीं देखा जाता, इसलिए पूरी तरह पठनीय कुंजी अपठनीय दिखती है। त्रुटि अक्सर खोलते समय निर्देशिका का नाम लिए बिना आती है, इसलिए अंतिम फ़ाइल को दोष दिया जाता है।
निर्देशिका के लिए, निष्पादन बिट का अर्थ खोज है, सामग्री चलाना नहीं। कुंजी डेटा ही रहती है, और इस मरम्मत के किसी भी भाग में इसे निष्पादन योग्य चिह्नित करने की आवश्यकता नहीं है।
सेवा खाते के रूप में पथ पर चलें
प्रत्येक घटक को उसके स्वामी और मोड के साथ सूचीबद्ध करें, फिर पठन को वास्तविक सेवा पहचान के रूप में दोहराएँ। आपके शेल और डेमॉन के बीच का अंतर अक्सर पूरा उत्तर होता है। प्रतीकात्मक लिंक को वास्तविक लक्ष्य तक ले जाएँ, क्योंकि हल किया गया पथ ही जाँचा जाता है।
namei -l /etc/openvpn/client/office.key
sudo -u vpn-reader stat -c '%A %U:%G %n' /etc/openvpn/client/office.key
एक सेवा फ़ाइलों को एक से अधिक चरणों में भी खोल सकती है। कुछ सामग्री विशेषाधिकार प्राप्त सेटअप के दौरान पढ़ी जाती है, जबकि अन्य फ़ाइलें विशेषाधिकार छोड़ने के बाद खोली जाती हैं। फ़ाइल पढ़ने वाला रूट शेल बाद के वर्कर की पहुँच को पुनः उत्पन्न नहीं करता। माउंट नामस्थान उसी पथ का अलग दृश्य प्रस्तुत कर सकता है, विशेषकर कंटेनर के भीतर, इसलिए डेमॉन के फ़ाइलसिस्टम दृश्य की तुलना अपने से करें।
सबसे संकीर्ण उपयुक्त अनुमति बदलें
प्रक्रिया को पहुँच देने वाली सबसे छोटी व्यवस्था चुनें: आवश्यक निर्देशिकाओं पर खोज वाला नियंत्रित समूह, सेवा के पास पहले से मौजूद प्रबंधित स्थान, या कोई अन्य प्रलेखित तंत्र। फ़ाइल पढ़ने के लिए उसकी निर्देशिका पर लेखन अनुमति आवश्यक नहीं है। विशेषाधिकार प्राप्त कॉन्फ़िगरेशन पर व्यापक समूह-लेखन अनुमति सामान्य ट्रैवर्सल मरम्मत नहीं है। पुनरावर्ती 0777 भी समाधान नहीं है।
लिखें कि आपने कौन सा घटक बदला और क्यों। बिना दर्ज कारण के अनुमति परिवर्तन की समीक्षा कठिन और उसे भूलना आसान है।
चलने के बाद ही मोड से आगे देखें
यदि मोड बिट पर्याप्त लगते हैं, तो शेष जाँचें ACL, सुरक्षा नीति और सैंडबॉक्स प्रतिबंध हैं। ACL ऐसी पहुँच दे सकता है जिसे मोड बिट अनुपस्थित बताते हैं, या ऐसी पहुँच रोक सकता है जिसे वे अनुमत दिखाते हैं। वे सेटिंग्स मौजूदा कॉन्फ़िगरेशन स्वामी की हैं, और उन्हें बंद करने के बजाय सँकरे रूप में समायोजित करना चाहिए। रूट या कार्य निर्देशिका का अंतर भी ऐसे निरपेक्ष पथ की व्याख्या कर सकता है जो एक संदर्भ में काम करता है और दूसरे में विफल होता है।
पहुँच ठीक करते समय यह न भूलें कि फ़ाइल क्या है। CA प्रमाणपत्र डिज़ाइन से सार्वजनिक है; निजी कुंजी नहीं। क्लाइंट जिन फ़ाइलों को फिर से लिखता है, उन्हें केवल-पठन पहचान कुंजी से भिन्न लेखन अधिकार चाहिए। रहस्य छापे बिना मेटाडेटा जाँचें, फिर पुष्टि करें कि बदलाव के बाद सेवा स्वयं काम करती है। सेवा प्रलेखन में एक छोटा नोट अगले व्यक्ति को वही चलना बचाता है।