OpenVPN کے user ڈراپ پر systemd سختی کو تہ نہ کریں

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

دو ماڈل، تبدیلی کا ایک مالک

پہلا ماڈل ڈیمون کا ہے۔ کمیونٹی OpenVPN کے user اور group اختیارات سرنگ اور چابیاں قائم ہونے کے بعد شناخت بدلتے ہیں، اور persist-key کے ساتھ persist-tun ان وسائل کو بعد میں بھی قابل استعمال رکھتے ہیں۔

دوسرا ماڈل سروس مینیجر کا ہے۔ systemd کی User= یا Group= ترتیب طے کرتی ہے کہ عمل کس شناخت کے تحت شروع ہو، اور صلاحیت کی ہدایات طے کرتی ہیں کہ وہ کیا رکھ سکتا ہے۔ ماڈلوں کے درمیان انتخاب سیکیورٹی سوال بننے سے پہلے پیکیجنگ کا سوال ہے، اور پیکیج کا نگہبان پہلے ہی اس کا جواب دے چکا ہے۔ آپ کا کام تیسرا آپشن ایجاد کرنا نہیں، وہی جواب تلاش کرنا ہے۔

دونوں جائز ہیں۔ غلطی یہ ہے کہ انہیں ایک ہی ڈیزائن کی تہوں کے طور پر دیکھا جائے، کیونکہ دوسرا ماڈل پہلے کی شناخت کی تبدیلی کو ایسا عمل بنا سکتا ہے جس کی اجازت عمل کو اب نہیں۔

طے کریں کہ شناخت کہاں بدلتی ہے

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

کچھ بھی تبدیل کرنے سے پہلے پڑھیں کہ نصب شدہ پیکیج واقعی کیا فراہم کرتا ہے، اس کی drop-in ڈائریکٹری سمیت۔ کچھ یونٹ جان بوجھ کر ڈیمون کی اپنی اترائی چھوڑ دیتے ہیں کیونکہ مینیجر پہلے ہی اسے سنبھالتا ہے، اور کچھ ابتدا کے بعد کی تبدیلی کے لیے ان اختیارات پر انحصار کرتے ہیں۔ کون سا ماڈل وراثت میں ملا، یہ جانے بغیر کوئی ایک ہٹانا ہی چلتی سروس کے شروع ہونا بند ہونے کا راستہ ہے۔

منتخب ماڈل ایک سطر میں لکھیں: مینیجر کی ملکیت یا ڈیمون کی ملکیت۔ ہر بعد کی ہدایت اس جملے سے ہم آہنگ ہونی چاہیے، اور مخلوط یونٹ کو سمجھوتا نہیں بلکہ خرابی سمجھا جانا چاہیے۔

صلاحیتیں حدیں ہیں، عطیات نہیں

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

جو واقعی کسی صلاحیت کو سروس کے گرد و نواح کے مجموعے میں رکھتا ہے وہ AmbientCapabilities= ہے۔ systemd کے عمل درآمد کا حوالہ دونوں ہدایات کو الگ الگ بیان کرتا ہے، اور یہی فرق آن لائن صلاحیتوں کے بارے میں بیشتر الجھی ہوئی مشوروں کی وضاحت کرتا ہے۔

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

زندگی کے دورانیے میں اختیار کی نقشہ کشی کریں

ہر مرحلے پر عمل کو کیا کرنا ہے، درج کریں: آغاز، مستحکم حالت، دوبارہ تصدیق اور انہدام۔ انٹرفیس بنانا، راستے بدلنا، محفوظ چابی پڑھنا اور مددگار کو بلانا سب ایک ہی لمحے یا ایک جیسی شرائط کے تحت نہیں ہوتے۔ فہرست کو صلاحیت کے مطابق ترتیب دینے سے پہلے مرحلے کے مطابق ترتیب دیں۔

استحکام کے اختیارات دوبارہ مذاکرات کے دوران وسائل بچاتے ہیں، اور وہ ایسی اجازتیں نہیں دیتے جو کبھی نہیں تھیں۔ جو چابی عمل آغاز میں نہیں پڑھ سکتا، وہ بعد میں بھی ناقابلِ مطالعہ رہے گی، استحکام کے جھنڈے کچھ بھی کہیں۔ جھنڈے وہی بچاتے ہیں جو پہلے سے کام کر رہا تھا۔

مشترکہ نہیں، مخصوص اکاؤنٹ استعمال کریں۔ OpenVPN کے ڈویلپرز nobody کو عام مثال کے طور پر استعمال کرنے کی عادت کے خلاف خبردار کرتے ہیں، کیونکہ میزبان پر دیگر سروسز پہلے ہی اس اکاؤنٹ کے تحت چل رہی ہو سکتی ہیں اور جو علیحدگی آپ سمجھتے ہیں وہ وہاں نہیں۔

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

منصوبہ لکھیں اور بحالی رسائی رکھیں

تعیناتی ریکارڈ میں مینیجر، آغاز کی شناخت، مطلوبہ مستحکم شناخت اور ہر عطیہ کو اس کے مطلوبہ عمل کے ساتھ نامزد کرنا چاہیے۔ وہی ریکارڈ اگلی تبدیلی کو تجربہ نہیں بلکہ قابلِ جائزہ بناتا ہے۔

ترمیم کے دوران کنسول رسائی دستیاب رکھیں، کیونکہ آغاز میں ناکام ہونے والا یونٹ دور سے ٹھیک کرنا مشکل ہے۔ تبدیلی کو مکمل کہنے سے پہلے دوبارہ آغاز اور مکمل ری بوٹ آزمائیں۔ دوبارہ آغاز سے بچ جانے والا یونٹ بھی نیٹ ورک اٹھنے سے پہلے ناکام ہو سکتا ہے۔

کامیابی ایک سمجھا ہوا کم سے کم اختیار کا زندگی دورانیہ ہے، ایسا عمل نہیں جو اتفاقاً غیر root نام کے تحت چل رہا ہو۔