SELinux अन्तर्गत Squid अस्वीकृतिहरूको निदान

Squid ले उत्पन्न गरेको HTTP पहुँच अस्वीकृति र अपरेटिङ सिस्टमको “Permission denied” फरक सीमामा हुन्छन्। Squid फाइल खोल्दै थियो, सकेट बाँध्दै थियो, बाहिर जोडिँदै थियो वा ग्राहक अनुरोध अस्वीकार गर्दै थियो निर्धारण गर्नुहोस्।

अडिट घटनालाई सहसम्बन्धित गर्नुहोस्

SELinux प्रणालीमा, सेवा त्रुटिलाई यसको अडिट रेकर्डसँग मिलाउनुहोस्। स्रोत डोमेन, लक्ष्य प्रकार, वस्तु वर्ग र अस्वीकृत अनुमतिले नीतिले कुन कार्य रोक्यो देखाउँछन्। सही Unix स्वामित्वले सुरक्षा लेबल उपयुक्त छ भनी प्रमाणित गर्दैन।

अनुकूलन सुन्ने पोर्टलाई सम्बन्धित पोर्ट लेबल चाहिन सक्छ। स्थानान्तरित लग वा क्यास डाइरेक्टरीलाई फाइल लेबलिङ चाहिन सक्छ। Squid लग-पथ असफलताका लागि, लेबललाई दोष दिनु अघि डाइरेक्टरी ट्राभर्सल र लेखक अनुमति पनि जाँच्नुहोस्। असामान्य बाहिर जाने सेवाको अनुमति फेरि अर्को कार्य हो; Red Hat का Squid SELinux उदाहरणहरूले यी केसहरू छुट्याउँछन्।

स्थापित वितरणको नीति र प्रशासन मार्गदर्शन प्रयोग गर्नुहोस्। प्याकेज पथ, लेबल र निर्बन्धन इमेजहरूबीच फरक हुन सक्छ। AppArmor प्रयोग गर्ने प्रणालीमा SELinux आदेश लागू गर्नुको सट्टा यसको प्रोफाइल जाँच्नुहोस्।

प्रमाणले देखाएको नीति वा स्थान सुधार्नुहोस्, तर होस्ट प्रवर्तन कायम राख्नुहोस्। होस्ट नीति समस्या समाधान भएपछि पनि Squid का आफ्नै ग्राहक प्रमाणीकरण र पहुँच नियम लागू रहन्छन्।