الخطوة 1: بدء عملية التحليل¶

إذا بدأ اسم المسار بحرف '/'، فإن دليل البحث المبدئي هو الدليل الجذر للعملية المستدعية. ترث العملية دليلها الجذر من العملية الأم. عادةً ما يكون هذا هو الدليل الجذر للتسلسل الهرمي للملفات. قد تحصل العملية على دليل جذر مختلف باستخدام استدعاء النظام chroot(2)، أو قد تستخدم مؤقتًا دليل جذر مختلف باستخدام openat2(2) مع تعيين العلم RESOLVE_IN_ROOT.

قد تحصل العملية على مساحة وصل خاصة تمامًا إذا كانت هي—أو أحد أسلافها—قد بدأت باستدعاء النظام clone(2) الذي كان لديه العلم CLONE_NEWNS مضبوطًا. هذا يعالج الجزء '/' من اسم المسار.

إذا لم يبدأ اسم المسار بحرف '/'، فإن دليل البحث المبدئي لعملية التحليل هو دليل العمل الحالي للعملية — أو في حالة استدعاءات النظام من نمط openat(2)، الوسيط dfd (أو دليل العمل الحالي إذا تم تمرير AT_FDCWD كوسيط dfd). يُورث دليل العمل الحالي من العملية الأم، ويمكن تغييره باستخدام استدعاء النظام chdir(2).

أسماء المسارات التي تبدأ بحرف '/' تُسمى أسماء مسارات مطلقة. أسماء المسارات التي لا تبدأ بحرف '/' تُسمى أسماء مسارات نسبية.

الخطوة 2: السير على طول المسار¶

اضبط دليل البحث الحالي على دليل البحث المبدئي. الآن، لكل مكون غير نهائي من اسم المسار، حيث المكون هو سلسلة فرعية محددة بحروف '/'، يتم البحث عن هذا المكون في دليل البحث الحالي.

إذا لم يكن لدى العملية إذن بحث على دليل البحث الحالي، يتم إرجاع خطأ EACCES ("تم رفض الإذن").

إذا لم يتم العثور على المكون، يتم إرجاع خطأ ENOENT ("لا يوجد ملف أو دليل من هذا القبيل").

إذا تم العثور على المكون، لكنه ليس دليلًا ولا رابطًا رمزيًا، يتم إرجاع خطأ ENOTDIR ("ليس دليلًا").

إذا تم العثور على المكون وكان دليلًا، نضبط دليل البحث الحالي على ذلك الدليل، وننتقل إلى المكون التالي.

إذا تم العثور على المكون وكان رابطًا رمزيًا، نقوم أولاً بحل هذا الرابط الرمزي (مع دليل البحث الحالي كدليل بحث مبدئي). عند حدوث خطأ، يتم إرجاع ذلك الخطأ. إذا لم تكن النتيجة دليلًا، يتم إرجاع خطأ ENOTDIR. إذا كان حل الرابط الرمزي ناجحًا وأرجع دليلًا، نضبط دليل البحث الحالي على ذلك الدليل، وننتقل إلى المكون التالي. لاحظ أن عملية التحليل هنا يمكن أن تتضمن التكرار إذا كان مكون البادئة ('dirname') لاسم المسار يحتوي على اسم ملف هو رابط رمزي يحل إلى دليل (حيث قد يحتوي مكون البادئة لذلك الدليل على رابط رمزي، وهكذا). لحماية النواة من تجاوز سعة المكدس، وأيضًا للحماية من رفض الخدمة، هناك حدود على أقصى عمق للتكرار، وعلى أقصى عدد من الروابط الرمزية المتبوعة. يتم إرجاع خطأ ELOOP عند تجاوز الحد الأقصى ("عدد كبير جدًا من مستويات الروابط الرمزية").

كما هو مطبق حاليًا على Linux، الحد الأقصى لعدد الروابط الرمزية التي سيتم اتباعها أثناء تحليل اسم المسار هو 40. قبل Linux 2.6.18، كان الحد على عمق التكرار هو 5. بدءًا من Linux 2.6.18، تم رفع هذا الحد إلى 8. في Linux 4.2، تمت إعادة صياغة كود تحليل اسم المسار في النواة لإزالة استخدام التكرار، بحيث يكون الحد الوحيد المتبقي هو الحد الأقصى البالغ 40 تحليلًا لاسم المسار بأكمله.

يمكن حظر تحليل الروابط الرمزية خلال هذه المرحلة باستخدام openat2(2)، مع تعيين العلم RESOLVE_NO_SYMLINKS.

الخطوة 3: العثور على الإدخال النهائي¶

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

. و ..¶

حسب الاصطلاح، كل دليل يحتوي على الإدخالين "." و ".."، اللذين يشيران إلى الدليل نفسه وإلى الدليل الأب، على التوالي.

ستفترض عملية تحليل المسار أن هذه الإدخالات لها معانيها الاصطلاحية، بغض النظر عما إذا كانت موجودة فعليًا في نظام الملفات الفعلي.

لا يمكن للمرء الصعود إلى ما بعد الجذر: "/.." هو نفسه "/".

نقاط الوصل¶

بعد أمر mount dev path، يشير اسم المسار "path" إلى جذر التسلسل الهرمي لنظام الملفات على الجهاز "dev"، ولم يعد يشير إلى ما كان يشير إليه سابقًا.

يمكن للمرء الخروج من نظام ملفات موصول: "path/.." يشير إلى الدليل الأب لـ "path"، خارج التسلسل الهرمي لنظام الملفات على "dev".

يمكن حظر عبور نقاط الوصل باستخدام openat2(2)، مع تعيين العلم RESOLVE_NO_XDEV (مع ملاحظة أن هذا يقيد أيضًا عبور وصل الربط).

الشرطات المائلة اللاحقة¶

إذا انتهى اسم مسار بـ '/'، فإن ذلك يُجبر تحليل المكون السابق كما في الخطوة 2: المكون الذي يسبق الشرطة المائلة إما موجود ويُحل إلى دليل أو يُسمى دليلًا سيُنشأ فورًا بعد تحليل اسم المسار. وإلا، يُتجاهل '/' اللاحق.

الرابط الرمزي النهائي¶

إذا كان المكون الأخير لاسم مسار رابطًا رمزيًا، فإنه يعتمد على استدعاء النظام ما إذا كان الملف المشار إليه سيكون الرابط الرمزي أو نتيجة تحليل المسار لمحتوياته. على سبيل المثال، يعمل استدعاء النظام lstat(2) على الرابط الرمزي، بينما يعمل stat(2) على الملف الذي يشير إليه الرابط الرمزي.

حد الطول¶

يوجد حد أقصى لطول أسماء المسارات. إذا كان اسم المسار (أو بعض اسم المسار الوسيط الذي تم الحصول عليه أثناء تحليل الروابط الرمزية) طويلًا جدًا، يُرجع خطأ ENAMETOOLONG ("اسم الملف طويل جدًا").

اسم المسار الفارغ¶

في UNIX الأصلي، كان اسم المسار الفارغ يشير إلى الدليل الحالي. في الوقت الحالي، ينص POSIX على أن اسم المسار الفارغ يجب ألا يُحل بنجاح. يُرجع Linux ENOENT في هذه الحالة.

الأذونات¶

تتكون بتات أذونات الملف من ثلاث مجموعات من ثلاث بتات؛ انظر chmod(1) و stat(2). تُستخدم المجموعة الأولى من الثلاث عندما يساوي معرف المستخدم الفعّال للعملية المستدعية معرف مالك الملف. تُستخدم المجموعة الثانية من الثلاث عندما يساوي معرف مجموعة الملف إما معرف المجموعة الفعّال للعملية المستدعية، أو يكون أحد معرفات المجموعة التكميلية للعملية المستدعية (كما هو محدد بواسطة setgroups(2)). عندما لا ينطبق أي منهما، تُستخدم المجموعة الثالثة.

من البتات الثلاث المستخدمة، تحدد البتة الأولى إذن القراءة، والثانية إذن الكتابة، والأخيرة إذن التنفيذ في حالة الملفات العادية، أو إذن البحث في حالة الدلائل.

يستخدم Linux fsuid بدلاً من معرف المستخدم الفعّال في فحوصات الأذونات. عادةً ما يساوي fsuid معرف المستخدم الفعّال، ولكن يمكن تغيير fsuid بواسطة استدعاء النظام setfsuid(2).

(هنا "fsuid" تعني شيئًا مثل "معرف مستخدم نظام الملفات". كانت الفكرة مطلوبة لتنفيذ خادم NFS في مساحة المستخدم في وقت كان بإمكان العمليات إرسال إشارة إلى عملية بنفس معرف المستخدم الفعّال. إنها قديمة الآن. لا ينبغي لأحد استخدام setfsuid(2).)

وبالمثل، يستخدم Linux fsgid ("معرف مجموعة نظام الملفات") بدلاً من معرف المجموعة الفعّال. انظر setfsgid(2).

تجاوز فحوصات الأذونات: المستخدم الفائق والإمكانيات¶

في نظام UNIX التقليدي، المستخدم الفائق (root، معرف المستخدم 0) هو كلي القدرة، ويتجاوز جميع قيود الأذونات عند الوصول إلى الملفات.

في Linux، تُقسم امتيازات المستخدم الفائق إلى إمكانيات (انظر capabilities(7)). هناك إمكانيتان ذات صلة بفحوصات أذونات الملفات: CAP_DAC_OVERRIDE و CAP_DAC_READ_SEARCH. (تمتلك العملية هذه الإمكانيات إذا كان fsuid الخاص بها هو 0.)

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

تمنح الإمكانية CAP_DAC_READ_SEARCH إذن القراءة والبحث على الدلائل، وإذن القراءة على الملفات العادية.