الخلاصة

  • أوصى RFC 2054 بمحاولة TCP على المنفذ 2049، ثم UDP 2049، ثم NFSv3 بالمقبض العام ذي الطول الصفري، قبل الرجوع حسب الخطأ إلى v2 وPORTMAP وMOUNT.
  • كان المقبض العام مرجعا ابتدائيا محجوزا، لا إثبات هوية ولا تفويضا للتصدير ولا ضمانا لسلامة المسار كله أو نجاح READ.
  • خفّض LOOKUP متعدد المكونات عدد الرسائل، لكنه أبقى شروطا مستقلة للمسار القياسي والمسار الأصلي للخادم والروابط الرمزية وعبور أنظمة الملفات.

البداية التقليدية كانت رحلتين منفصلتين

عمل NFS فوق ONC RPC. كانت خدمة الربط على المنفذ 111 تربط رقم البرنامج بمنفذ مخصص. ولأن MOUNT لم يملك منفذا معروفا، سأل العميل PORTMAP عن موقعه، ثم أرسل MOUNTPROC_MNT ليحصل على مقبض ينشئه الخادم لمسار مصدّر. بعد ذلك فقط بدأت عمليات NFS.

قسّم هذا الترتيب المسؤوليات، لكنه أضاف جولات انتظار وجعل منفذ MOUNT المتغير صعب المرور عبر مرشحات الحزم والوكلاء. لاحظ RFC 2054 أن كثيرا من خوادم NFS تسجل الخدمة على 2049 بصورة ثابتة، وحوّل العادة إلى فرضية قابلة للتراجع: محاولة TCP 2049، ثم UDP 2049 عند رفض الاتصال، وعدم سؤال PORTMAP إلا إذا لم يستجب النقلان.

الاستجابة على 2049 تثبت أمرا ضيقا: سطح برنامج أجاب في ذلك العنوان والمنفذ. لا تثبت إصدار NFS ولا معنى WebNFS ولا الهوية ولا الإذن ولا نجاح النقل اللاحق.

نوع الخطأ يحدد موضع الرجوع

بعد الاتصال يفترض العميل WebNFS وNFSv3، ويرسل عادة LOOKUP بالمقبض العام v3. تعني PROG_MISMATCH أن فرضية إصدار البرنامج لم تصح، ولذلك يعيد المحاولة بـ NFSv2 ومقبضه العام.

أما NFS3ERR_STALE وNFS3ERR_INVAL وNFS3ERR_BADHANDLE فتنفي تعرف الخادم على القيمة العامة. عندها يجب العثور على MOUNT بواسطة PORTMAP والحصول على مقبض تقليدي. رفض TCP وصمت UDP وعدم تطابق الإصدار ورفض المقبض ليست أسماء لعطل واحد؛ كل إشارة تقود إلى علاج مختلف.

الصفر نقطة لقاء لا وثيقة صلاحية

ينشئ الخادم مقابض NFS المعتادة وتبقى قيمتها مبهمة للعميل. الاستثناء العام هو 32 ثمانية صفرياً في NFSv2، وطول صفري في NFSv3. لا يحمل inode ولا اسم تصدير ولا مستخدما ولا سرا ولا حقا. إنه يستدعي معنى خاصا من موضع يختاره مدير الخادم.

يضع RFC 2055 حدا لكلمة «عام». إذا لم تكن الوجهة في نظام ملفات مصدّر، وجب إرجاع خطأ. وحتى الوصول إلى نظام ثان مصدّر قد يُرفض: الخادم الذي يعتمد على فحص الوصول وقت MOUNT لا يستطيع منح التصدير الثاني تلقائيا عندما جرى تجاوز MOUNT. يستطيع الخادم الذي يفحص التصدير في كل طلب NFS أن يتصرف بمرونة أكبر، لكن السلطة تأتي من الفحص لا من الصفر.

طلب واحد حمل مكونات أكثر ولم يحمل يقينا أوسع

كان LOOKUP العادي يحل اسما واحدا بالنسبة إلى مقبض مجلد. سمح WebNFS، فقط بالنسبة إلى المقبض العام، بإرسال a/b/c في طلب واحد وإرجاع مقبض المكون الأخير.

بقيت للمسار قواعد. البداية ASCII اختارت مسارا قياسيا مفصولا بشرطات مائلة مع ترميزات الهروب. الشرطة المائلة الأولى جعلت التقييم من جذر الخادم؛ ومن دونها بدأ من المجلد المرتبط بالمقبض العام. أما الثمانية الأولى 0x80 فاختارت صيغة المسار الأصلية للخادم. كل صيغة عقد تفسير مستقل.

حلّ الخادم الروابط الرمزية في المكونات الوسطى. وإذا كان المكون الأخير رابطا، أعاد مقبض الرابط ليستخدم العميل READLINK. الهدف المطلق أعيد تقييمه من المقبض العام؛ والهدف النسبي استُبدل في موقع الرابط قبل LOOKUP جديد. حدد RFC 2054 هذه المعالجة للعميل فقط عندما يأتي الرابط من بحث قياسي متعدد المكونات.

ولا يعبر LOOKUP العادي عادة نقطة تركيب في الخادم. لا يسمح البحث العام بالعبور إلا إذا كان نظام الوجهة مصدّرا وكان الخادم يدعم معنى العبور في RFC 2055. المقبض الناتج يثبت عملية تسمية واحدة في وقت وسياسة محددين، ولا يضمن سلامة كل الطريق دائما.

ثلاث إيصالات لا تصبح تفويضا واحدا

استجابة المنفذ، وقبول المقبض الصفري، ونجاح LOOKUP حقائق منفصلة. يتطلب إثبات الوصول إلى الملف أيضا هوية الجهة المقصودة، والمصادقة والسلامة عند الحاجة، وإذن التصدير والعملية، ومعالجة الرابط والعبور، والمحتوى المتوقع، واكتمال READ. أما ثبات التخزين والنتيجة العملية فلهما أدلة أخرى.

ورث RFC 2054 اعتبارات أمان NFS وRPC، وسمح بالتفاوض المستقل على المصادقة وسلامة البيانات والخصوصية. لم يمنح القيمة الصفرية وظائفها.

المصادر