RFC 2307 وLDAP والسلطة التي يحملها uidNumber

الخلاصة

اقترح RFC 2307 تمثيل حسابات Unix ومجموعاتها وموارد الشبكة في LDAP. ويضم الصنف posixAccount الحقل uidNumber الذي تستخدمه برامج النظام للعثور على المستخدم.
حذّر قسم الأمن في الوثيقة من أن تمكين المستخدم من تعديل uidNumber قد يجعل حسابه مكافئاً للمستخدم الفائق؛ لذلك ربطت الخطر بمن يملك حق الكتابة على سجلات النظام.

البحث عن الحساب يبدأ برقم

لا يسأل برنامج Unix الدليل عن قصة صاحب الحساب. إنه يمرر عدداً إلى مكتبة C وينتظر سجل الحساب المرتبط به. يشرح RFC 2307 هذا المسار من خلال getpwuid()، وهي دالة تبحث عن بيانات الحساب باستخدام رقم المستخدم. في نموذج LDAP المقترح، تبحث الخدمة عن سجل posixAccount الذي يطابق فيه uidNumber الرقم الذي مرره البرنامج.

يبدو الرقم خانة في سجل. لكن النظام يعامله بوصفه هوية تشغيلية.

قبل دخول LDAP إلى هذه القصة، كانت شبكات Unix تستخدم Network Information Service (NIS) لمشاركة معلومات الحسابات والأجهزة. يصف دليل Sun لإدارة Solaris خرائط NIS على أنها جداول من مفتاح وقيمة. يحتفظ الخادم الرئيسي بخرائط النطاق، وتحتفظ الخوادم التابعة بنسخ منها، ويستطيع العميل الاستعلام من أي منهما. تتيح passwd.byname البحث باسم الدخول، بينما تستخدم passwd.byuid رقم المستخدم مفتاحاً. ينشئ المسؤول الخرائط في الخادم الرئيسي انطلاقاً من ملفات محلية، ثم يوزعها على الخوادم التابعة.

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

يسجل دليل SunOS لعام 1999 حاشيةً عن الاسم: كان NIS يسمى سابقاً Sun Yellow Pages، ثم تغير الاسم بسبب علامة تجارية بريطانية مع بقاء الوظيفة كما هي. تغير الاسم التجاري، أما خريطة الحسابات فاحتفظت بدورها العملي.

LDAP نقل السجل، أما الصلاحية فبقيت قراراً إدارياً

حددت مواصفة LDAPv3 في RFC 2251، الصادرة في ديسمبر 1997، طريقة أخف في الموارد للوصول إلى أدلة مبنية على X.500 مقارنةً بـ DAP الكامل. وبعدها بنحو ثلاثة أشهر، نشر RFC 2307 بعنوان An Approach for Using LDAP as a Network Information Service. اقترحت الوثيقة صنوف LDAP وسماته لبيانات Unix وTCP/IP.

لم يقتصر النطاق على أسماء المضيفين. شمل الحسابات والمجموعات، وأسماء الخدمات وأرقام البروتوكولات، ومعرّفات RPC، ومعلمات التشغيل، وعناوين الشبكة ومجموعات NIS. يستطيع posixAccount حفظ اسم الدخول والاسم المعروض وuidNumber وgidNumber ومجلد المنزل وصدفة الدخول. كما عرض RFC مثالاً على تحويل سطر من ملف شبيه بـ /etc/passwd إلى سمات في الدليل.

كان لهذا الربط منطق تشغيلي. تطبيقات Unix كانت تسأل مكتبة C عن الحسابات أصلاً؛ ويمكن تغيير المصدر من ملف محلي إلى دليل شبكي مع الإبقاء على نمط البحث الذي تستخدمه البرامج. يورد قسم التنفيذ في RFC 2307 خادم NIS يستخدم LDAP بدلاً من الملفات المحلية، وتنفيذاً مرجعياً لبحث مكتبة C، وبرامج تستورد ملفات مثل /etc/passwd و/etc/hosts إلى LDAP.

نشر RFC 2307 ضمن فئة Experimental ولم يأمر كل مواقع Unix بالانتقال إلى LDAP. تقول الوثيقة إن الطريقة نُفذت بنجاح في بعض البيئات، لكنها لا تحصي عدد المواقع أو تقيس انتشارها.

الرقم يحدد موضع السلطة

يشرح قسم الأمن في RFC 2307 القوة التي قد يحملها سجل دليل على مستوى نظام التشغيل. ينبغي، بحسب الوثيقة، ألا يغير سجلات كيانات النظام إلا المسؤولون. والسبب محدد: إذا استطاع المستخدم تغيير uidNumber الخاص به، فقد يقوّض الأمن بجعل حسابه مكافئاً للمستخدم الفائق.

يصوغ RFC 2307 الخطر على نحو مشروط ويحدد نقطة التحكم. يربط برنامج Unix الرقم بحساب؛ ويمكن للدليل نشر هذه المطابقة أمام عملاء كثيرين؛ ومن يملك صلاحية الكتابة يستطيع تغيير الهوية التي يتلقاها أولئك العملاء. يحدد المخطط شكل الحقل. وتحدد قائمة التحكم بالوصول من يستطيع تغيير أثره.

ويلفت القسم نفسه إلى تصادم آخر بين سهولة البحث وحماية الأسرار. إذا استطاع مستخدمون غير مميزين قراءة تجزئات كلمات المرور المشفرة بطرق شائعة مثل crypt()، أمكن تعريضها لهجمات القاموس والتخمين الشامل. ربط RFC هذه الصيغة بالتوافق مع أنظمة Unix القائمة، وأوصى بخدمة مصادقة أقوى عندما تكون الحماية مهمة. يسهل الدليل المشترك البحث، لكنه قد يوسع أيضاً نطاق من يستطيع قراءة بيانات الحساب الحساسة.

إذن، ما تثبته الوثائق هو اقتراح التصميم والتحذير الذي سجله مؤلفوه. أما مدى انتشار استخدام LDAP لهذا الغرض بين أنظمة Unix فلا يظهر في هذه المصادر؛ ويلزم لذلك سجل نشر مستقل أو إحصاء موثق.

التغيير الجوهري ليس إضافة مخطط إلى قاعدة بيانات. إنه قبول نظام التشغيل أن تأتي إجابة سؤال محلي من الشبكة. قد يكون uidNumber عموداً واحداً، لكن البرنامج الذي يقرأه هو من يمنحه معناه. وعندما ينتقل مصدر الحساب من /etc/passwd إلى NIS أو LDAP، تنتقل معه نقاط التحكم: من يملك المرجع المعتمد، وأي نسخة تحمل الخريطة الأحدث، ومن يستطيع تغيير رقم الهوية؟