لماذا يظهر تحذير مسح مسار vpnc داخل حاوية

غالبًا ما تنتهي سجلات الحاويات الجديدة بشكوى Read-only file system حول /proc/sys/net/ipv4/route/flush، ويُلام ذلك السطر على نفق قد يكون سليمًا تمامًا. الكتابة التي يقف خلفها تستهدف مدخلًا في النواة لم يعد يفعل شيئًا مفيدًا بعد اختفاء ذاكرة مسارات IPv4. داخل حاوية يُحمَّل /proc/sys للقراءة فقط، لذا يُرفض التحويل قبل أن تصل أي قيمة وتطبع الصدفة ذلك الرفض. يمكن لنفق عامل أن يطبع هذا التحذير ما دام السطر القديم باقيًا في النص، ولا يجعل --privileged الكتابة ذات معنى أبدًا.

ما كان النص يحاول مسحه

كانت نصوص الاتصال الأقدم تنتهي بتنظيف ذاكرة مؤقتة: كتابة قيمة في ملف تحكم في النواة وطلب من مكدس IPv4 إسقاط ذاكرة التوجيه المؤقتة، حتى يُختار مسار نفق جديد دون انتظار انتهاء صلاحية المدخلات القديمة. كان الملف معنونًا تحت /proc/sys/net/ipv4/، ما جعل العملية تحويلًا في الصدفة لا أمر توجيه. أزالت النواة 3.6 تلك الذاكرة، ومعها سبب وجود المسح. لا شيء في مسار البيانات الحالي يعتمد على تلك الكتابة.

نجا المدخل نفسه كملف قديم للكتابة فقط، فالنص الذي ما زال يكتب فيه يصل إلى مسار حقيقي وإلى فحص أذونات حقيقي. على المضيف تعود الكتابة بالنجاح ولا تغيّر شيئًا. في حاوية يصطدم التحويل نفسه بملف /proc/sys للقراءة فقط ويفشل مع EROFS، وهو ما تطبعه الصدفة كرسالة نظام الملفات للقراءة فقط. على أنوية يكون فيها المسار غائبًا فعلًا تصبح الصياغة No such file or directory، ولا يتغير الاستنتاج.

يقول الخطآن شيئين مختلفين، والفرق يستحق الحفظ. Read-only file system يعني أن النواة وصلت إلى مدخل ورفضت الكتابة؛ No such file or directory يعني أن المدخل اختفى. لا تبلغ أي من الرسالتين عن جهاز النفق أو المسارات أو تحليل الأسماء، لذا لا يمكن لأي منهما تبرير مزيد من الامتيازات.

الترتيب هو ما يجعل الرسالة تبدو سببية. يثبّت نص الاتصال المسارات ويغيّر حالة الواجهة ويعيد كتابة تحليل الأسماء قبل أن يصل إلى التنظيف في النهاية، لذا يكون السطر الأخير المطبوع هو السطر الذي يقتبسه الناس حتى عندما يعود كل خطوة مهمة بالنجاح. النفق الذي يؤسس ويحمل حركة المرور بينما يطبع هذا التحذير يطابق الآلية أعلاه تمامًا.

افحص التركيب والمسار قبل إضافة الامتياز

ثلاث قراءات تفصل التحذير الشكلي عن الفشل الحقيقي: هل ما زال النص المثبت يحمل السطر، وكيف يُحمَّل /proc/sys، وإلى أين تذهب حركة التطبيق فعليًا. نفّذها في نفس نطاق أسماء الحاوية أو على المضيف الذي ظهر فيه التحذير، لأن فحصًا على جهاز غير ذي صلة يجيب عن سؤال مختلف.

grep -n 'ipv4/route/flush' /usr/share/vpnc-scripts/vpnc-script
findmnt -no OPTIONS /proc/sys
ip -4 route get 10.20.5.10

جواب grep أضعف مما يبدو، لأن العثور عليه يثبت وجود السطر لا أنه يعمل دون حماية؛ يمكن لنص مُصان أن يحمل الكتابة داخل حارس يتخطاها. findmnt -no OPTIONS /proc/sys يحسم التركيب مباشرة، كما أن ro في ذلك الخرج يعني أن كل كتابة تحت تلك النقطة مرفوضة مهما فعل النص. ثم يُظهر بحث المسار هل تُحل الوجهة التي يحتاجها التطبيق عبر واجهة النفق أم عبر بوابة الحاوية الافتراضية. بحث يختار البوابة الافتراضية يعني أن النفق ارتفع ولا شيء يوجّه إليه، وهذه مشكلة توجيه لا مشكلة امتياز.

أين يُشحن الإصلاح فعليًا

الإصلاح المُصان يعيش في النص لا في أعلام الحاوية. غيّر نص vpnc-script المنبعي طريقة تعامله مع هذه العملية، لذا قارن النسخة داخل الصورة بالمنبع الحالي وحدّث عبر الحزمة أو بناء الصورة التي توفره. الملف المحرر يدويًا داخل حاوية عاملة غير قابل للمراجعة ولن يبقى بعد البناء التالي.

--privileged موثق بأنه يمنح كل القدرات مع وصول واسع إلى الأجهزة، وهو تنازل كبير مقابل رسالة لا تغيّر شيئًا، لذا سمِّ القدرة الناقصة بدلًا من ذلك إن كانت غائبة فعلًا. بعد التحديث، كرر بحث المسار ودع تطبيقًا يستخدم النفق، لأن سجلًا هادئًا واتصالًا عاملًا نتيجتان منفصلتان.