डेवलपर टूल · chmod कैलकुलेटर
nginx को ठीक करना 403 निषिद्ध: फ़ाइल और निर्देशिका अनुमतियाँ जो मायने रखती हैं
· यह क्यों मायने रखती है
chmod Unix अभिगम नियंत्रण
Nginx से 403 अक्सर एक फ़ाइल सिस्टम समस्या होती है, कॉन्फ़िगरेशन समस्या नहीं। यह पोस्ट दिखाती है कि यह कैसे जांचा जाए कि कौन सा उपयोगकर्ता nginx चलता है और पथ में प्रत्येक निर्देशिका पर उसे कौन से बिट्स की आवश्यकता है।
403 एक स्थिर साइट पर जो स्थानीय रूप से काम करती है - फ़ाइलें /home/deploy से आती हैं और nginx कहता है कि प्रत्येक URL के लिए निषिद्ध है
एक nginx 403 में मोड बिट्स शामिल हो सकते हैं, लेकिन यह मार्ग इसके कारण की पहचान नहीं कर सकता है। कैलकुलेटर में कोई nginx एकीकरण, लॉग, कॉन्फ़िगरेशन पार्सर, प्रक्रिया लुकअप या पथ वॉकर नहीं है। यह संकीर्ण प्रश्नों का उत्तर देता है: क्या एक निर्देशिका वर्ग ने निष्पादित किया है और क्या एक नियमित-फ़ाइल वर्ग ने पढ़ा है, जिससे अन्यत्र एकत्र किए गए साक्ष्य की व्याख्या करने में मदद मिलती है।
डिफ़ॉल्ट मानने के बजाय प्रत्येक पथ घटक पर देखे गए सटीक मोड से प्रारंभ करें। प्रत्येक मोड दर्ज करें और उसका लक्ष्य प्रकार चुनें। प्रतीकात्मक पाठ, चेकबॉक्स और गद्य वर्ग अनुमतियों को उजागर करते हैं और रूपांतरण की पुष्टि करते हैं, लेकिन यह नहीं दिखा सकते कि nginx ने पहुंच का प्रयास किया, किस पहचान का उपयोग किया या क्या फ़ाइल सिस्टम अनुमतियों ने प्रतिक्रिया उत्पन्न की।
403 में मोड बिट्स शामिल हो सकते हैं, लेकिन यह रूट इसके कारण की पहचान नहीं कर सकता है
कैलकुलेटर nginx कार्यकर्ता की पहचान नहीं खोज सकता। यह स्वामी, समूह और अन्य वर्गों को मॉडल करता है, लेकिन कोई उपयोगकर्ता नाम, प्रक्रिया या सदस्यता नहीं देता है। इसलिए rwxr-xr-x जैसा कोई मोड इस बारे में कुछ नहीं कहता है कि क्या कर्मचारी वस्तु का मालिक है, उसके समूह से संबंधित है या दूसरे के अंतर्गत आता है। बाहरी निरीक्षण को वह वर्गीकरण स्थापित करना होगा।
प्रासंगिक बिट्स के बारे में दावों से पहले पहचान की खोज होनी चाहिए। एक बार जब साक्ष्य लागू वर्ग स्थापित कर देता है, तो मैट्रिक्स 4 के रूप में पढ़ा जाता है, 2 के रूप में लिखा जाता है और 1 के रूप में निष्पादित होता है। इससे पहले, समूह या अन्य का संपादन अनुमान का काम है। मार्ग कोई प्रक्रिया स्थिति नहीं पढ़ता; यह सर्वर आर्किटेक्चर का अनुमान लगाने के बजाय आपूर्ति किए गए मोड का अनुवाद करता है।
कैलकुलेटर nginx कार्यकर्ता की पहचान का पता नहीं लगाता है
प्रत्येक निर्देशिका घटक का एक अलग आपूर्ति किए गए मोड के रूप में निरीक्षण करें। निर्देशिकाओं के लिए, निष्पादन प्रविष्टि और नाम-आधारित पहुंच की अनुमति देता है, पढ़ना सूचीकरण की अनुमति देता है, और लिखना प्रविष्टियों को बनाने, नाम बदलने और हटाने की अनुमति देता है। लक्ष्य-विशिष्ट स्पष्टीकरण समीक्षकों को यह निर्धारित करने में मदद करता है कि बाहरी रूप से स्थापित वर्ग ने पथ का निरीक्षण करने का दावा किए बिना किसी विशेष घटक पर अमल किया है या नहीं।
ब्राउज़र रूट से वेब रूट तक नहीं चलता है। यह अवरुद्ध घटक का पता नहीं लगा सकता, अस्तित्व की पुष्टि नहीं कर सकता या एCAल का निरीक्षण नहीं कर सकता। प्रत्येक देखे गए निर्देशिका मोड को अलग से आपूर्ति करें, फिर अंतिम ऑब्जेक्ट को एक नियमित फ़ाइल के रूप में जांचें, जहां पढ़ने की चिंता लिस्टिंग के बजाय सामग्री से है। यह फ़ाइल सिस्टम निरीक्षण को प्रतिस्थापित करने के बजाय एकत्रित साक्ष्य की व्याख्या करता है।
फ़ाइलों को r की आवश्यकता है, और कुछ नहीं - क्यों 644 स्थिर फ़ाइलों के लिए पर्याप्त है और क्यों फ़ाइलों पर 755 ठीक नहीं है
एक स्थिर फ़ाइल के लिए, 644 rw-r--r-- प्रस्तुत करता है। मालिक को पढ़ना और लिखना प्राप्त होता है, जबकि समूह और अन्य को पढ़ना प्राप्त होता है; किसी को निष्पादन प्राप्त नहीं होता. यह रूपांतरण दर्शाता है कि फ़ाइल पढ़ना और निष्पादित करना अलग-अलग बिट हैं। पेज के पास यह तय करने का कोई आधार नहीं है कि किसी विशेष सर्वर को निष्पादित करने की आवश्यकता है या नहीं, क्योंकि सर्वर नीति अनुपस्थित है।
फ़ाइल और निर्देशिका स्पष्टीकरण को अलग रखें। निर्देशिका निष्पादन का अर्थ है प्रविष्टि और नाम-आधारित पहुंच योग्यता, जबकि नियमित-फ़ाइल निष्पादन का अर्थ है प्रोग्राम चलाना। इसलिए उसी चेकबॉक्स में लक्ष्य-विशिष्ट गद्य है। 755 के साथ 644 की तुलना करने से बिट्स स्पष्ट हो जाते हैं, लेकिन 403 का निदान नहीं किया जा सकता है या कॉन्फ़िगरेशन, पहचान, ACL और नीति संदर्भ के बिना एक सार्वभौमिक मोड निर्धारित नहीं किया जा सकता है।
काम किया गया उदाहरण: पथ पर /home/deploy/site/index.html - namei -l और ls -l लाइन का पता लगाना जो अवरोधक को प्रकट करता है
एक समर्थित उदाहरण अन्यत्र पथ साक्ष्य एकत्र होने के बाद शुरू होता है। मान लीजिए निर्देशिका घटक 755 हैं और अंतिम फ़ाइल 644 है। कैलकुलेटर निर्देशिकाओं को rwxr-xr-x के रूप में प्रस्तुत करता है, समूह और अन्य निष्पादन को प्रविष्टि और पहुंच के रूप में समझाता है। यह फ़ाइल को rw-r--r-- के रूप में प्रस्तुत करता है, समूह और अन्य पठन को सामग्री पहुंच के रूप में समझाता है।
यदि एक घटक 750 है, तो इसका अन्य त्रिक --- है, जबकि समूह r-x रहता है। यह अंतर मायने रख सकता है, लेकिन यह साबित नहीं करता कि nginx अन्य का उपयोग करता है। मार्ग namei या ls नहीं चला सकता, इसलिए बाहरी साक्ष्य को पथ और मोड की आपूर्ति करनी चाहिए। इसके बाद यह समीक्षा के दौरान प्रतिलेखन त्रुटियों को कम करने के लिए प्रत्येक प्रतिनिधित्व को सिंक्रनाइज़ करता है।
कार्यान्वित उदाहरण: पथ के प्रत्येक घटक के लिए आपूर्ति किए गए मोड का निरीक्षण करें
स्वामित्व संबंधी निर्णय रूपांतरण मोड के बाहर रहते हैं। पैनल किसी मालिक या समूह को नहीं पढ़ता है और कोई चाउन या CAचजीआरपी ऑपरेशन की पेशकश नहीं करता है। यह तैनाती, सेवा या साझा-समूह स्वामित्व के बीच चयन नहीं कर सकता है, न ही चलती सामग्री का आकलन कर सकता है। उन निर्णयों के लिए स्रोतों से अनुपस्थित सिस्टम और कार्यभार साक्ष्य की आवश्यकता होती है; कोई भी उत्पन्न मोड उस संदर्भ को प्रतिस्थापित नहीं कर सकता।
एक बार स्वामित्व का समाधान कहीं और हो जाए, तो तुलना करें कि मोड कैसे पहुंच को विभाजित करते हैं। मोड 750 पूर्ण स्वामी अनुमतियाँ देता है, समूह को पढ़ने और निष्पादित करने की अनुमति देता है, और अन्य को कुछ नहीं देता; 755 अन्य पढ़ने और निष्पादित करने को जोड़ता है। यह श्रमिक वर्ग को जानने पर आधारित है। निष्क्रिय कमांड पूर्वावलोकन न तो स्वामित्व बदलता है और न ही सर्वर पहुंच की पुष्टि करता है।
स्वामित्व विकल्प मोड रूपांतरण के बाहर रहते हैं
कॉन्फ़िगरेशन, सूचकांक चयन, अनिवार्य पहुंच नियंत्रण और अपस्ट्रीम व्यवहार का निदान यहां नहीं किया गया है। कोई भी स्रोत nginx कॉन्फ़िगरेशन को लोड नहीं करता है, URI या इंडेक्स की जाँच नहीं करता है, लॉग नहीं पढ़ता है, किसी अपस्ट्रीम से संपर्क नहीं करता है, या SELinux या AppArmor का अवलोकन नहीं करता है। इसलिए आपूर्ति किए गए मोड को सही ढंग से परिवर्तित करने से यह स्थापित नहीं हो सकता कि nginx ने 403 क्यों लौटाया; सर्वर साक्ष्य को उस प्रश्न का उत्तर अवश्य देना चाहिए।
जब कोई मोड संदिग्ध लगे तो इस अंतर को बनाए रखें। पैनल दिखा सकता है कि निर्देशिका वर्ग में निष्पादन का अभाव है या फ़ाइल वर्ग में पढ़ने का अभाव है, लेकिन प्रासंगिकता पहचान और पथ साक्ष्य पर निर्भर करती है। अनुमेय बिट्स अन्य कारणों को भी बाहर नहीं कर सकते। बताएं कि मोड किस चीज़ की अनुमति देता है, फिर सर्वर-विशिष्ट डायग्नोस्टिक्स पर वापस लौटें।
कॉन्फ़िगरेशन, अनुक्रमणिका, MAC और अपस्ट्रीम कारणों का निदान नहीं किया गया है
पथ पहुंच प्रत्येक घटक पर निर्भर हो सकती है, फिर भी कैलकुलेटर एक समय में एक आपूर्ति मूल्य देखता है। इसकी ताकत सटीक डिकोडिंग है: ऑक्टल, प्रतीकात्मक पाठ और चेकबॉक्स सिंक्रनाइज़ रहते हैं, जबकि निर्देशिका गद्य लिस्टिंग, संशोधन और प्रविष्टि को अलग करता है। यह घटकों या पहुंच का प्रयास करने वाली प्रक्रिया की खोज का दिखावा किए बिना समीक्षा को सरल बनाता है।
सर्वर पहचान स्थापित करें और इस रूट के बाहर पथ मोड एकत्र करें। बाह्य रूप से सत्यापित वर्ग पर ध्यान केंद्रित करते हुए, प्रत्येक निर्देशिका को एक निर्देशिका के रूप में और अंतिम ऑब्जेक्ट को एक नियमित फ़ाइल के रूप में डिकोड करें। कॉन्फ़िगरेशन, एCAल और अनिवार्य नीति की अलग से जांच करें। कैलकुलेटर अंकगणित को मान्य करता है, लेकिन 403 के कारण की पहचान नहीं कर सकता या किसी समाधान को सत्यापित नहीं कर सकता।