লগ বাড়ছে কিন্তু পুনরায় তৈরি হচ্ছে না: ডিরেক্টরির ACL পরীক্ষা করুন
একটি ফাইলে অ্যাপেন্ড করতে তার ডিরেক্টরিতে নতুন নাম লাগে না, কিন্তু তৈরি করতে লাগে। কিছুই প্রসারিত করার আগে অ্যাক্সেস ACL-এর সঙ্গে উত্তরাধিকারসূত্রে পাওয়া ডিফল্ট তুলনা করুন।
ক্রমাগত বাড়তে থাকা একটি লগ যেই মুহূর্তে কিছু এটি পুনরায় তৈরি করে তখনই বাড়া বন্ধ করে দেয়, আর ত্রুটিটি বলে permission denied। প্রলুব্ধকর সিদ্ধান্ত হলো লগ ফাইলটিরই আরও অনুমতি দরকার, অথচ ফাইলটি একই অ্যাকাউন্টের জন্য ইতিমধ্যেই লেখার উপযোগী হতে পারে। বিদ্যমান নামে অ্যাপেন্ড করা আর নতুন নাম তৈরি করা আলাদা দুই পরীক্ষা, এবং শুধু দ্বিতীয়টিই ডিরেক্টরির সঙ্গে পরামর্শ করে।
অ্যাপেন্ড আর তৈরি আলাদা পরীক্ষা
বিদ্যমান ফাইল অ্যাপেন্ডের জন্য খুলতে ওই ফাইলে লেখার অধিকার এবং তার পথের প্রতিটি ডিরেক্টরিতে অনুসন্ধানের অধিকার দরকার। ফাইল তৈরি করতে ধারণকারী ডিরেক্টরিতে লেখা ও অনুসন্ধান দরকার, কারণ ক্রিয়াটি সেখানে একটি নাম যোগ করে। পুনঃনামকরণের মাধ্যমে ফাইল প্রতিস্থাপন উভয় ডিরেক্টরি ও তাদের sticky bit নিয়মকেও ছুঁয়ে যায়।
| 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অ্যাক্সেস এন্ট্রিগুলো ডিফল্ট থেকে আলাদা করে পড়ুন, এবং মাস্ক পড়ুন। পূর্ণ অধিকার তালিকাভুক্ত একটি নামযুক্ত এন্ট্রিও মাস্ক দ্বারা সীমিত হতে পারে, তাই কার্যকর মন্তব্যটি প্রথম লাইনের অক্ষরের চেয়ে বেশি গুরুত্বপূর্ণ।
কনফিগারেশনের পথের বদলে সমাধানকৃত পথ ব্যবহার করুন। সিমলিংক, মাউন্ট পয়েন্ট বা ঘোরানো ডিরেক্টরি প্রকৃত ফাইলকে এমন জায়গায় রাখতে পারে যেখানে আপনি দেওয়া অনুমতি কখনো পৌঁছায় না। প্রথমে নাম টুল দিয়ে পথ হাঁটুন, তারপর প্রতিটি স্তর প্রশ্নের অ্যাকাউন্টের সঙ্গে মেলান। শীর্ষ ডিরেক্টরিতে অনুমান করাই হলো সমাধান এক স্তর বেশি উঁচুতে পড়ার উপায়।
সেই মুহূর্তে কে লেখে তা চিহ্নিত করুন
কিছু বদলানোর আগে সার্ভিস ইউনিট, তার drop-in এবং ডেমনের নিজস্ব অ্যাকাউন্ট সেটিংস পরীক্ষা করুন। যে প্রক্রিয়া অ্যাপেন্ড করে আর যে প্রক্রিয়া পুনরায় তৈরি করে তারা আলাদা হতে পারে: রোটেশন সহায়ক, স্ট্যাটাস লেখক আর ওয়েব পাঠক খুব কমই এক পরিচয় ভাগ করে।
root শেল থেকে পরীক্ষামূলক চালানো সীমাবদ্ধ সার্ভিস পুনরুৎপাদন করে না, এবং সার্ভিস ব্যর্থ হতে থাকলেও সেটি সফল হবে। একই ইউনিট, একই অ্যাকাউন্ট ও একই স্যান্ডবক্স সেটিংসের অধীনে ব্যর্থ ক্রিয়াটি পুনরুৎপাদন করুন। না পারলে অস্থায়ী শেল দিয়ে ইউনিট চালু করুন এবং এটি যে পরিচয় জানায় তা পরীক্ষা করুন। অন্য যেকোনো কিছু আপনার টার্মিনাল মাপে, সার্ভিস নয়।
যদি সত্যিই তৈরি দরকার হয়, লেখককে নিবেদিত লগ ডিরেক্টরিতে অ্যাক্সেস দিন আর গ্রাহকদের পড়ার অ্যাক্সেস আলাদা রাখুন। একটি লগ কল মেটাতে শেয়ারড অ্যাকাউন্ট বা পুরো অ্যাপ্লিকেশন ট্রি লেখার উপযোগী করা ছোট সমস্যাকে বড় সমস্যার সঙ্গে বদলানো।
আবার ফিরিয়ে না এনে রোটেট করুন
যে ফাইলটি পুনরায় তৈরি করে সে-ই পরবর্তী চক্রের জন্য তার মালিক ও মোড ঠিক করে, তাই রোটেশন কনফিগারেশনের সঙ্গে সমাধানটি সমন্বয় করুন। ভিন্ন অ্যাকাউন্টে বা নতুন ACL নিয়ে তৈরি প্রতিস্থাপন সফল সংশোধনের পরেও ব্যর্থতা ফিরিয়ে আনে।
মোড ও গ্রুপ তৈরি করার সময়েই সেট করুন, পরে নয়, আর পরের অ্যাপেন্ডের বদলে পরের রোটেশন যাচাই করুন। অ্যাপেন্ড কেবল সেই পরীক্ষাই পুনরাবৃত্তি করে যা ইতিমধ্যে পাস করেছে। রোটেশন টুল তৈরি-মোড সেটিং দিলে তৈরি করার পরের chmod-এর বদলে সেটিই ব্যবহার করুন। তৈরি আর chmod-এর মধ্যবর্তী ফাঁকই ঠিক সেই সময় যখন পরের লেখা ব্যর্থ হতে পারে।
তবুও ছাঁটা ব্যর্থ হলে অনুমতি যোগ করা বন্ধ করুন
আপনি যে ফাইলে লিখতে পারেন তা ছাঁটতে ব্যর্থ হওয়া ডিরেক্টরি অনুমতিতে ব্যাখ্যা হয় না, আর আরও অনুমতি যোগ করলে সাহাযও হবে না। বরং অ্যাট্রিবিউট ও সীমাবদ্ধতার দিকে তাকান: append-only অ্যাট্রিবিউট কেবল অ্যাপেন্ড মোডে লেখার অনুমতি দেয়, আর শুধু-পঠনযোগ্য মাউন্ট বা সার্ভিস স্যান্ডবক্স এমন ক্রিয়া প্রত্যাখ্যান করতে পারে যা ACL অনুমোদন করে।
ইউনিটের ফাইলসিস্টেম সীমাবদ্ধতা ও পথের মাউন্ট অপশন পরীক্ষা করুন, তারপর ঠিক যে ক্রিয়াটি ব্যর্থ হয়েছিল তা পুনরুৎপাদন করুন। যে অনুমতি কখনো জিজ্ঞাসা করা হয়নি তা প্রসারিত করা কেবল লুকায় কোন সীমাবদ্ধতাটি বাস্তব ছিল। নিষ্পত্তিযোগ্য ইউনিটে একবারে একটি সীমাবদ্ধতা সরান, আর স্থায়ী কিছু বদলানোর আগে তা ফিরিয়ে দিন।