लग लगातार बढ्छ तर पुनः सिर्जना गर्न सकिँदैन: डाइरेक्टरीको ACL जाँच्नुहोस्
फाइलमा थप्न त्यसको डाइरेक्टरीमा नयाँ नाम चाहिँदैन; सिर्जना गर्न चाहिन्छ। केही फराकिलो बनाउनु अघि पहुँच ACL लाई वंशानुगत पूर्वनिर्धारितसँग तुलना गर्नुहोस्।
निरन्तर बढिरहेको लग कुनै कुराले पुनः सिर्जना गरेको क्षणमै बढ्न छोड्छ, र त्रुटिले अनुमति अस्वीकृत भयो भन्छ। लग फाइललाई नै बढी अनुमति चाहिन्छ भन्ने लोभ्याउने निष्कर्ष हो, तर फाइल त्यही खाताका लागि पहिले नै लेख्नयोग्य हुन सक्छ। अवस्थित नाममा थप्ने र नयाँ नाम सिर्जना गर्ने दुइ फरक जाँच हुन्, र दोस्रोले मात्र डाइरेक्टरीलाई सोध्छ।
थप्ने र सिर्जना गर्ने फरक जाँच हुन्
अवस्थित फाइल थप्न खोल्न त्यो फाइलमा लेखन पहुँच र त्यसको मार्गका हरेक डाइरेक्टरीमा खोज पहुँच चाहिन्छ। फाइल सिर्जना गर्न त्यसलाई राख्ने डाइरेक्टरीमा लेखन र खोज चाहिन्छ, किनकि कार्यले त्यसमा नाम थप्छ। नाम परिवर्तन गरी फाइल प्रतिस्थापन गर्दा दुवै डाइरेक्टरी र तिनका स्टिकी-बिट नियम पनि छुन्छ।
| Operation | What must permit it | Typical failure message |
|---|---|---|
| Append to an existing log | File write access, path traversal | Permission denied on the file |
| Create a missing log | Directory write and search access | Permission denied on the path |
| Rename a replacement into place | Both directories, plus sticky restrictions | Permission denied or operation not permitted |
पहिले नै खुला डिस्क्रिप्टरले चौथो अवस्था थप्छ। प्रक्रियाले विशेषाधिकार छोड्नु अघि खोलेको लेखन ह्यान्डल राखिरहन सक्छ र पनि आफ्नो पछिको पहिचानमा त्यही मार्ग पुनः खोल्न असफल हुन सक्छ। सफल थप र असफल सिर्जना दुवै एउटै प्रक्रियाका लागि, एउटै क्षणमा सत्य हुन सक्छन्।
पूर्वनिर्धारित ACL वंशानुगत हुन्छन्, तिनीहरू दिँदैनन्
पूर्वनिर्धारित उपसर्गबाट सुरु हुने प्रविष्टिले नयाँ वस्तुहरूले डाइरेक्टरीबाट के वंशानुगत पाउँछन् भन्ने वर्णन गर्छ। यसले डाइरेक्टरीलाई नै केही दिँदैन, र पहिले नै अवस्थित फाइलको ACL मर्मत गर्दैन।
namei -l /var/log/openvpn/server.log
getfacl -p /var/log/openvpn
getfacl -p /var/log/openvpn/server.logपहुँच प्रविष्टिहरू पूर्वनिर्धारितबाट छुट्टै पढ्नुहोस्, र मास्क पढ्नुहोस्। पूर्ण अधिकार सूचीबद्ध गर्ने नामित प्रविष्टि पनि मास्कले सीमित हुन सक्छ, त्यसैले प्रभावकारी टिप्पणी पहिलो पङ्क्तिका अक्षरभन्दा बढी महत्त्वपूर्ण छ।
कन्फिगरेसनको मार्गको सट्टा समाधान गरिएको मार्ग प्रयोग गर्नुहोस्। सिमलिङ्क, माउन्ट बिन्दु वा घुमाइएको डाइरेक्टरीले वास्तविक फाइललाई तपाईंले दिएको अनुमति कहिल्यै नपुग्ने ठाउँमा राख्न सक्छ। पहिले नाम उपकरणले मार्ग हिँड्नुहोस्, त्यसपछि हरेक तहलाई सम्बन्धित खातासँग तुलना गर्नुहोस्। माथिल्लो तहको डाइरेक्टरी अनुमान गर्नु नै सुधार एक तह धेरै माथि अवतरण हुने तरिका हो।
त्यो क्षणमा कसले लेख्छ पहिचान गर्नुहोस्
केही परिवर्तन गर्नु अघि सेवा इकाइ, त्यसका ड्रप-इन र डेमनको आफ्नै खाता सेटिङ जाँच्नुहोस्। थप्ने प्रक्रिया र पुनः सिर्जना गर्ने प्रक्रिया फरक हुन सक्छन्: रोटेसन सहायक, स्थिति लेखक र वेब पाठकले पहिचान विरलै साझा गर्छन्।
root शेलबाट चलाइएको परीक्षणले प्रतिबन्धित सेवा पुनरुत्पादन गर्दैन, र सेवा असफल हुँदै गर्दा त्यो सफल हुनेछ। असफल कार्यलाई त्यही इकाइमुनि, त्यही खाता र त्यही स्यान्डबक्स सेटिङसँग पुनरुत्पादन गर्नुहोस्। सक्नुहुन्न भने इकाइलाई अस्थायी शेलसँग सुरु गरी त्यसले रिपोर्ट गर्ने पहिचान जाँच्नुहोस्। अरू जे पनि सेवालाई होइन, तपाईंको टर्मिनललाई नाप्छ।
सिर्जना साँच्चै आवश्यक भए लेखकलाई समर्पित लग डाइरेक्टरीमा पहुँच दिनुहोस् र उपभोक्ताका लागि पढ्ने पहुँच छुट्टै राख्नुहोस्। एउटै लगिङ कल पूरा गर्न साझा खाता वा सम्पूर्ण अनुप्रयोग रूख लेख्नयोग्य बनाउनु सानो समस्यालाई ठूलोसँग साट्नु हो।
पुनः नल्याई घुमाउनुहोस्
जसले फाइल पुनः सिर्जना गर्छ उसैले अर्को चक्रका लागि त्यसको मालिक र मोड तय गर्छ, त्यसैले सुधारलाई रोटेसन कन्फिगरेसनसँग समन्वय गर्नुहोस्। अर्को खातामुनि वा नयाँ ACL सहित सिर्जना गरिएको प्रतिस्थापनले सफल सुधारपछि पनि विफलता फर्काउँछ।
मोड र समूह सिर्जनाकै क्रममा सेट गर्नुहोस्, पछि होइन, र अर्को थपको सट्टा अर्को रोटेसन प्रमाणित गर्नुहोस्। थपले पहिले नै उत्तीर्ण भएको परीक्षण दोहोर्याउँछ मात्र। रोटेसन उपकरणले सिर्जना मोड सेटिङ दिन्छ भने सिर्जनापछिको chmod को सट्टा त्यो प्रयोग गर्नुहोस्। सिर्जना र chmod बीचको अन्तर नै अर्को लेखन असफल हुन सक्ने ठ्याक्कै क्षण हो।
काट्दा पनि असफल भए अनुमति थप्न छोड्नुहोस्
तपाईं लेख्न सक्ने फाइल काट्न असफल हुनु डाइरेक्टरी अनुमतिले व्याख्या गर्दैन, र ती थप्दा सहयोग हुँदैन। बरु गुण र सीमालाई हेर्नुहोस्: append-only गुणले थप मोडमा मात्र लेखन अनुमति दिन्छ, र पढ्ने-मात्र माउन्ट वा सेवा स्यान्डबक्सले ACL ले अनुमति दिने कार्य अस्वीकार गर्न सक्छ।
इकाइको फाइलसिस्टम प्रतिबन्ध र मार्गका माउन्ट विकल्प जाँच्नुहोस्, त्यसपछि असफल भएको ठ्याक्कै कार्य पुनरुत्पादन गर्नुहोस्। कहिल्यै नसोधिएको अनुमति फराकिलो बनाउनु कुन प्रतिबन्ध वास्तविक थियो भन्ने मात्र लुकाउँछ। अस्थायी इकाइमा एकैचोटि एउटा प्रतिबन्ध फाल्नुहोस्, र कुनै स्थायी परिवर्तन गर्नु अघि फर्काउनुहोस्।