लॉग वाढतो पण पुन्हा तयार होत नाही: डिरेक्टरीचा ACL तपासा

सतत वाढणारा लॉग, काहीतरी त्याला पुन्हा तयार करते त्या क्षणी वाढणे थांबवतो, आणि त्रुटी सांगते की परवानगी नाकारली. लॉग फाइललाच अधिक परवानग्या हव्यात हा मोहक निष्कर्ष आहे, पण फाइल त्या खात्यासाठी आधीच लिहिण्यायोग्य असू शकते. विद्यमान नावात जोडणे आणि नवीन नाव तयार करणे या दोन वेगळ्या तपासण्या आहेत, आणि फक्त दुसरीच डिरेक्टरीला विचारते.

जोडणे आणि तयार करणे वेगळ्या तपासण्या आहेत

विद्यमान फाइल जोडण्यासाठी उघडण्यास त्या फाइलवर लेखन प्रवेश आणि तिच्या मार्गातील प्रत्येक डिरेक्टरीत शोध प्रवेश लागतो. फाइल तयार करण्यास ती धारण करणाऱ्या डिरेक्टरीवर लेखन आणि शोध लागतो, कारण क्रिया तिला नाव जोडते. नाव बदलून फाइल बदलणे दोन्ही डिरेक्टऱ्यांना आणि त्यांच्या स्टिकी-बिट नियमांनाही स्पर्श करते.

आधीच उघडलेला डिस्क्रिप्टर चौथी स्थिती जोडतो. प्रक्रिया विशेषाधिकार सोडण्यापूर्वी उघडलेली लेखन हँडल धरून ठेवू शकते आणि तरीही तिच्या नंतरच्या ओळखीने तोच मार्ग पुन्हा उघडण्यात अपयशी ठरू शकते. यशस्वी जोडणी आणि अपयशी निर्मिती एकाच प्रक्रियेसाठी, एकाच क्षणी दोन्ही खऱ्या असू शकतात.

डीफॉल्ट 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 परवानगी देत असलेली क्रिया नाकारू शकतात.

युनिटचे फाइलसिस्टम प्रतिबंध आणि मार्गाचे माउंट पर्याय तपासा, नंतर अपयशी झालेली नेमकी क्रिया पुनरुत्पादित करा. कधीही विचारले न गेलेली परवानगी रुंदावणे कोणता प्रतिबंध खरा होता हेच लपवते. टाकाऊ युनिटमध्ये एकावेळी एक प्रतिबंध काढा, आणि काहीही कायमस्वरूपी बदलण्यापूर्वी तो परत आणा.