PrivateTmp: hook نے فائل لکھی، پھر وہ کہاں گئی؟

Hooks کامیابی کی اطلاع دیتے ہیں، اور وہی راستہ shell سے اب بھی خالی دکھتا ہے۔ دونوں بیانات بیک وقت درست ہو سکتے ہیں، کیونکہ systemd سروس اپنی mount نام کی جگہ میں نجی عارضی ڈائریکٹری کے ساتھ رہ سکتی ہے۔ یہ سمجھ میں آنے کے بعد دلچسپ سوال یہ ہے کہ لکھائی آخرکار کامیاب ہوئی یا نہیں۔

دو عارضی ڈائریکٹریاں، ایک ہی راستہ

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

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

غیر مرئی کو ناقابل تحریر سے الگ کریں

کامیاب لکھائی اور ناکام کھلنا مختلف ثبوت دیتے ہیں، اور یہی فرق مرمت کا فیصلہ کرتا ہے۔ اگر hook کہے کہ فائل بن گئی مگر باہر کا پڑھنے والا اسے نہیں پاتا، تو آپ کے پاس نام کی جگہ کا سوال ہے۔ اگر hook اجازت کی خرابی یا ناکام کھلنے کی اطلاع دے، تو فائل کبھی نہیں لکھی گئی اور نام کی جگہ کی کوئی تبدیلی مدد نہیں کرے گی۔

systemctl show [email protected] -p PrivateTmp -p User -p Group -p RuntimeDirectory
systemctl show [email protected] -p MainPID --value
sudo ls -l /proc/PID/root/tmp/client-state

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

مشترکہ ڈیٹا کو واضح جگہ دیں

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

[Service]
RuntimeDirectory=openvpn-hook-office
RuntimeDirectoryMode=0750

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

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

استحقاق کی دو تہیں متفق نہیں ہو سکتیں

سروس مینیجر یونٹ کے ترتیب شدہ صارف کے لیے ڈائریکٹری بناتا ہے، جبکہ VPN ڈیمن کنکشن hook چلانے سے پہلے الگ سے اپنے اکاؤنٹ میں اتر سکتا ہے۔ یہ مختلف تہیں ہیں، اور یہ مختلف شناختیں بتا سکتی ہیں۔

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

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

پوری منتقلی کی تصدیق کریں

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

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