لاگ بڑھتا ہے مگر دوبارہ تخلیق نہیں ہو سکتا: ڈائریکٹری کا ACL دیکھیں

مسلسل بڑھتا ہوا لاگ اسی لمحے بڑھنا بند کر دیتا ہے جب کوئی چیز اسے دوبارہ تخلیق کرتی ہے، اور خرابی کہتی ہے کہ اجازت مسترد ہوئی۔ دلکش نتیجہ یہ ہے کہ خود لاگ فائل کو زیادہ اجازتیں درکار ہیں، تاہم فائل اسی اکاؤنٹ کے لیے پہلے ہی قابل تحریر ہو سکتی ہے۔ موجودہ نام میں اضافہ اور نیا نام تخلیق کرنا دو مختلف جانچیں ہیں، اور صرف دوسری ہی ڈائریکٹری سے رجوع کرتی ہے۔

اضافہ اور تخلیق مختلف جانچیں ہیں

موجودہ فائل کو اضافے کے لیے کھولنے میں اس فائل پر تحریر کی رسائی اور اس کے راستے کی ہر ڈائریکٹری میں تلاش کی رسائی درکار ہے۔ فائل تخلیق کرنے میں اسے رکھنے والی ڈائریکٹری پر تحریر اور تلاش درکار ہے، کیونکہ عمل اس میں نام کا اضافہ کرتا ہے۔ نام بدل کر فائل کی تبدیلی دونوں ڈائریکٹریوں اور ان کے اسٹکی بٹ قواعد کو بھی چھوتی ہے۔

پہلے سے کھلا ڈسکرپٹر چوتھی صورت کا اضافہ کرتا ہے۔ عمل استحقاق چھوڑنے سے پہلے کھلا تحریری ہینڈل رکھ سکتا ہے اور پھر بھی اپنی بعد کی شناخت میں وہی راستہ دوبارہ کھولنے میں ناکام ہو سکتا ہے۔ کامیاب اضافے اور ناکام تخلیق ایک ہی عمل کے لیے، ایک ہی لمحے میں دونوں درست ہو سکتے ہیں۔

طے شدہ 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 اجازت دیتا ہے۔

یونٹ کی فائل سسٹم پابندیاں اور راستے کے ماؤنٹ اختیارات دیکھیں، پھر ناکام ہونے والا عین عمل دوبارہ پیدا کریں۔ کبھی نہ پوچھی گئی اجازت کو وسیع کرنا صرف یہ چھپاتا ہے کہ کون سی پابندی حقیقی تھی۔ ایک ہی بار میں ایک پابندی ہٹائیں ایک ضائع ہونے والے یونٹ میں، اور کوئی مستقل تبدیلی کرنے سے پہلے اسے واپس رکھیں۔