लॉग में जोड़ होता रहता है पर फिर से नहीं बनता: निर्देशिका का 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एक्सेस प्रविष्टियों को डिफ़ॉल्ट से अलग पढ़ें, और मास्क पढ़ें। पूर्ण अधिकार सूचीबद्ध करने वाली नामित प्रविष्टि भी मास्क से सीमित हो सकती है, इसीलिए प्रभावी टिप्पणी पहली पंक्ति के अक्षरों से अधिक मायने रखती है।
कॉन्फ़िगरेशन के पथ के बजाय हल किए गए पथ का उपयोग करें। सिमलिंक, माउंट पॉइंट या घुमाई गई निर्देशिका वास्तविक फ़ाइल को ऐसी जगह रख सकते हैं जहाँ आपकी दी गई अनुमति कभी नहीं पहुँचती। पहले नाम उपकरण से पथ पर चलें, फिर हर स्तर की तुलना संबंधित खाते से करें। शीर्ष-स्तरीय निर्देशिका का अनुमान लगाना ही वह तरीका है जिससे सुधार एक स्तर ऊँचा बैठता है।
पहचानें कि उस क्षण कौन लिखता है
कुछ भी बदलने से पहले सेवा यूनिट, उसके ड्रॉप-इन और डेमॉन की अपनी खाता सेटिंग जाँचें। जोड़ने वाली प्रक्रिया और फिर से बनाने वाली प्रक्रिया अलग हो सकती हैं: रोटेशन सहायक, स्थिति लेखक और वेब पाठक शायद ही एक ही पहचान साझा करते हैं।
रूट शेल से चलाया गया परीक्षण प्रतिबंधित सेवा को दोहराता नहीं है, और वह सफल होगा जबकि सेवा विफल होती रहेगी। विफल क्रिया को उसी यूनिट, उसी खाते और उसी सैंडबॉक्स सेटिंग के अंतर्गत दोहराएँ। यदि आप ऐसा नहीं कर सकते, तो यूनिट को अस्थायी शेल के साथ शुरू करें और उसकी बताई पहचान जाँचें। बाकी कुछ भी सेवा के बजाय आपके टर्मिनल को मापता है।
यदि निर्माण वास्तव में आवश्यक है, तो लेखक को समर्पित लॉग निर्देशिका तक पहुँच दें और उपभोक्ताओं के लिए पढ़ने की पहुँच अलग रखें। एक लॉगिंग कॉल को संतुष्ट करने के लिए साझा खाते या पूरे एप्लिकेशन ट्री को लिखने योग्य बनाना छोटी समस्या को बड़ी से बदल देता है।
बिना दोबारा लाए घुमाएँ
जो फ़ाइल को फिर से बनाता है वही अगले चक्र के लिए उसका स्वामी और मोड तय करता है, इसलिए सुधार को रोटेशन कॉन्फ़िगरेशन के साथ समन्वयित करें। किसी अलग खाते के अंतर्गत या ताज़ा ACL के साथ बनाया गया प्रतिस्थापन सफल सुधार के बाद विफलता लौटा देता है।
मोड और समूह को निर्माण के समय सेट करें, बाद में नहीं, और अगले जोड़ के बजाय अगले रोटेशन को सत्यापित करें। जोड़ केवल उस परीक्षण को दोहराता है जो पहले ही पास हो चुका है। यदि रोटेशन उपकरण क्रिएट-मोड सेटिंग देता है, तो निर्माण के बाद chmod के बजाय उसका उपयोग करें। निर्माण और chmod के बीच का अंतराल ठीक वही समय है जब अगला लेखन विफल हो सकता है।
जब काटना फिर भी विफल हो, तो अनुमतियाँ जोड़ना बंद करें
ऐसी फ़ाइल को काटने की विफलता जिसमें आप लिख सकते हैं, निर्देशिका अनुमतियों से नहीं समझाई जाती, और उन्हें और जोड़ने से मदद नहीं मिलेगी। इसके बजाय विशेषताओं और सीमाओं को देखें: append-only विशेषता केवल जोड़ मोड में लेखन की अनुमति देती है, और केवल-पढ़ने वाला माउंट या सेवा सैंडबॉक्स ऐसी क्रिया को अस्वीकार कर सकते हैं जिसे ACL अनुमति देता है।
यूनिट के फ़ाइलसिस्टम प्रतिबंध और पथ के माउंट विकल्प जाँचें, फिर ठीक वही विफल क्रिया दोहराएँ। जिस अनुमति से कभी परामर्श ही नहीं लिया गया, उसे बढ़ाना केवल यह छिपाता है कि कौन-सी सीमा वास्तविक थी। एक अस्थायी यूनिट में एक बार में एक सीमा हटाएँ, और कोई स्थायी बदलाव करने से पहले उसे वापस लाएँ।