في جملة واحدة
chmod هو أمر Unix الذي يحدد من يمكنه قراءة ملف أو الكتابة إليه أو تنفيذه، وهو بمثابة نظام التحكم في الوصول الأساسي لمعظم خوادم العالم وأجهزة المطورين.
المشكلة التي يحلها
تخيل الأيام الأولى للحوسبة: شخص واحد، جهاز واحد، مهمة واحدة في كل مرة. في نظام كهذا، صلاحيات الملفات هي حل يبحث عن مشكلة. إذا كنت الشخص الوحيد الذي سيستخدم الكمبيوتر على الإطلاق، فممن تحمي الملفات؟ من نفسك؟
ثم جاء نظام Unix في أواخر الستينات في مختبرات بيل (Bell Labs). كانت فكرته الثورية هي أن يكون نظام تشغيل متعدد المستخدمين ومتعدد المهام منذ البداية. فجأة، أصبح لديك عدة مبرمجين مسجلين دخولهم على نفس الحاسوب المركزي (mainframe) عبر طرفيات مختلفة، ويعملون جميعًا في نفس الوقت. هذا خلق مشكلة جديدة وعاجلة: كيف تمنع "دينيس" من حذف مترجم لغة C الجديد الخاص بـ "كين" عن طريق الخطأ (أو "عن طريق الخطأ")؟ كيف تسمح لشريكك في المشروع بقراءة الكود الخاص بك ولكن تمنعه من تغييره؟ كيف تحمي ملفات نظام التشغيل الأساسية من متدرب أخرق؟
كان الحل نظامًا بسيطًا وقويًا بشكل جميل للملكية والصلاحيات مدمجًا في نظام الملفات نفسه. كل ملف ومجلد سيكون له مالك، وينتمي إلى مجموعة، وله مجموعة محددة من الصلاحيات لثلاث فئات من المستخدمين: المالك، وأعضاء المجموعة، والجميع.
الأمر الخاص بـ "تغيير وضع" (change the mode) الملف - أي تعديل هذه الصلاحيات - سُمي chmod. وأصبح الأداة العالمية لمديري الأنظمة والمستخدمين للإعلان: "هذا الملف ملكي، وهذه هي قواعد التعامل معه." لقد حل مشكلة الفوضى متعددة المستخدمين بفعالية لدرجة أن نفس النموذج الأساسي لا يزال يستخدم اليوم على كل خادم Linux، وجهاز macOS، وهاتف Android، وجهاز IoT على هذا الكوكب تقريبًا.
كيف يعمل من الداخل
في جوهره، نظام chmod هو شبكة 3x3 من القواعد، مع بعض العلامات الخاصة للإثارة. لفهمه، تحتاج إلى فهم الأنواع الثلاثة من الصلاحيات والفئات الثلاث من المستخدمين التي يمكن تطبيقها عليهم.
الصلاحيات الثلاث: القراءة والكتابة والتنفيذ
كل شيء يدور حول ثلاثة إجراءات أساسية يمكنك القيام بها على ملف أو مجلد. يتم تمثيلها بالأحرف r و w و x.
- Read (
r): القدرة على فتح وعرض محتويات الملف. - Write (
w): القدرة على تعديل أو تغيير أو حذف محتويات الملف. - Execute (
x): القدرة على تشغيل الملف كبرنامج أو سكريبت.
ولكن هنا أول نقطة مربكة: هذه الصلاحيات تعني أشياء مختلفة قليلاً بالنسبة للمجلد. وهذه نقطة شائعة جدًا للالتباس.
| الصلاحية | على ملف | على مجلد |
|---|---|---|
Read (r) |
يمكن رؤية محتويات الملف | يمكن عرض أسماء الملفات في المجلد (باستخدام ls) |
Write (w) |
يمكن تغيير محتويات الملف | يمكن إنشاء أو إعادة تسمية أو حذف الملفات داخل المجلد |
Execute (x) |
يمكن تشغيل الملف | يمكن الدخول إلى المجلد (باستخدام cd) والوصول إلى الملفات بداخله |
فكر في النقطة الأخيرة. إذا لم يكن لدى المجلد صلاحية التنفيذ (x) لك، فلا يمكنك الدخول إليه باستخدام cd، حتى لو كان بإمكانك رؤية محتوياته! أنت بحاجة إلى x للمرور عبر "باب" المجلد.
فئات المستخدمين الثلاث: المالك، المجموعة، الآخرون
صلاحيات Unix ليست عالمية؛ بل يتم تخصيصها لفئات محددة من المستخدمين.
- Owner (
u): مستخدم واحد يمتلك الملف. عادةً، هذا هو الشخص الذي أنشأه. المالك لديه أكبر قدر من التحكم. - Group (
g): كل ملف ينتمي إلى مجموعة. هذا يسمح للمالك بمشاركة الوصول مع أعضاء فريق معينين. على سبيل المثال، يمكن أن تنتمي جميع ملفات "مشروع أبولو" إلى مجموعةapollo-devs. - Others (
o): حرفيًا كل شخص آخر. أي مستخدم على النظام ليس المالك ولا ينتمي إلى مجموعة الملف.
عندما ترى سلسلة صلاحيات مثل rwxr-xr--، فهي في الواقع ثلاث مجموعات من صلاحيات rwx مدمجة معًا للمالك (Owner)، والمجموعة (Group)، والآخرين (Others)، بهذا الترتيب.
rwx: المالك يمكنه القراءة والكتابة والتنفيذ.r-x: المجموعة يمكنها القراءة والتنفيذ، ولكن ليس الكتابة.r--: الآخرون يمكنهم القراءة فقط.
الترميزان: الرمزي مقابل الثماني
هناك طريقتان لإخبار chmod بما تريده، والمطورون يترجمون بينهما باستمرار.
1. الترميز الرمزي (الطريقة "السهلة")
يستخدم الترميز الرمزي الأحرف التي تعلمناها بالفعل (r, w, x و u, g, o, a حيث a تعني "الكل"). تستخدم + لإضافة صلاحية، و - لإزالتها، و = لتعيينها بالضبط.
# إعطاء المالك صلاحية التنفيذ
$ chmod u+x my_script.sh
# إزالة صلاحية الكتابة للمجموعة والآخرين
$ chmod go-w sensitive_data.txt
# تعيين الصلاحيات بالضبط: المالك يمكنه القراءة/الكتابة، المجموعة يمكنها القراءة، الآخرون ليس لديهم أي صلاحيات
$ chmod u=rw,g=r,o= config.yml
هذه الطريقة رائعة لإجراء تغييرات صغيرة ومستهدفة.
2. الترميز الثماني (طريقة "المهووسين")
الترميز الثماني (Octal) أسرع، وأكثر شيوعًا في السكريبتات، ويعتمد على النظام الثنائي. كل صلاحية (r, w, x) هي بت (bit) في رقم مكون من 3 بت.
r(read) هو البت الأول، بقيمة 4.w(write) هو البت الثاني، بقيمة 2.x(execute) هو البت الثالث، بقيمة 1.
تجمع الأرقام معًا للحصول على الصلاحيات التي تريدها.
| الرقم | ثنائي (rwx) |
الصلاحيات الممنوحة |
|---|---|---|
| 0 | 000 (---) |
لا شيء |
| 1 | 001 (--x) |
تنفيذ |
| 2 | 010 (-w-) |
كتابة |
| 3 | 011 (-wx) |
كتابة وتنفيذ |
| 4 | 100 (r--) |
قراءة |
| 5 | 101 (r-x) |
قراءة وتنفيذ |
| 6 | 110 (rw-) |
قراءة وكتابة |
| 7 | 111 (rwx) |
قراءة وكتابة وتنفيذ |
رمز ثماني مكون من ثلاثة أرقام مثل 755 يمثل صلاحيات المالك، والمجموعة، والآخرين.
chmod 755 my_script.sh يعني:
- المالك:
7(rwx) - قراءة، كتابة، وتنفيذ. - المجموعة:
5(r-x) - قراءة وتنفيذ. - الآخرون:
5(r-x) - قراءة وتنفيذ.
هذه صلاحية شائعة جدًا للسكريبتات القابلة للتنفيذ والتي تكون آمنة للآخرين لتشغيلها. صلاحية شائعة لملف هي 644 (المالك يمكنه القراءة/الكتابة، والجميع يمكنهم القراءة فقط).
الضيوف الخاصون: SUID، SGID، و Sticky Bit
بالإضافة إلى rwx الأساسية، هناك ثلاثة أوضاع خاصة، يتم تمثيلها برقم ثماني رابع في البداية (مثلًا، chmod 4755).
- SUID (Set User ID) - ثماني
4: عند تشغيل ملف قابل للتنفيذ يحمل هذا البت، فإنه يعمل بصلاحيات مالك الملف، وليس المستخدم الذي قام بتشغيله. المثال الكلاسيكي هو أمرpasswd، الذي يحتاج إلى تعديل ملف/etc/shadowالمحمي. الملف التنفيذيpasswdمملوك من قبلrootويحمل بت SUID، لذلك عندما يقوم مستخدم عادي بتشغيله، فإنه يكتسب مؤقتًا صلاحياتrootلهذه العملية الواحدة فقط. إنها قوية ولكنها خطيرة. - SGID (Set Group ID) - ثماني
2: مشابه لـ SUID، ولكن الملف التنفيذي يعمل بهوية مجموعة الملف. والأكثر فائدة، عند تعيينه على مجلد، فإن أي ملف أو مجلد جديد يتم إنشاؤه بداخله سيرث تلقائيًا مجموعة المجلد الأصل، وليس المجموعة الأساسية للمستخدم الذي أنشأه. هذا ضروري لمجلدات المشاريع المشتركة. - Sticky Bit - ثماني
1: له تاريخ غريب، ولكن اليوم يستخدم بشكل حصري تقريبًا على المجلدات. عندما يكون لدى مجلد بت الـ sticky (مثل مجلد/tmpفي النظام)، يمكن لجميع المستخدمين إنشاء ملفات فيه، ولكن لا يمكن للمستخدم حذف أو إعادة تسمية سوى الملفات التي يمتلكها هو نفسه. يمنع هذا العبث بملفات الآخرين في مساحة مشتركة.
قصص من الواقع
قضية السكريبت الذي لا يعمل
مطور مبتدئ، أليكس، يكتب سكريبت شل (shell script) رائع لأتمتة نشر الخادم. يقوم بعمل commit لـ deploy.sh إلى Git. على خادم الإنتاج، يقوم بعمل clone للمستودع، يكتب ./deploy.sh، ويضغط على Enter. الرد: bash: ./deploy.sh: Permission denied. يصاب بالذعر. هل كسر الخادم؟ مطور أقدم منه يكتب بهدوء ls -l deploy.sh ويظهر له المخرجات: -rw-r--r--. كان للملف صلاحيات القراءة والكتابة، ولكن ليس التنفيذ (x). Git لا يحافظ على صلاحيات التنفيذ افتراضيًا. بعد أمر سريع chmod +x deploy.sh، عمل السكريبت بشكل مثالي.
الدرس: الملفات، خاصة من مصادر مثل Git أو أرشيفات zip، ليست قابلة للتنفيذ بشكل افتراضي. يجب عليك منح صلاحية تشغيلها بشكل صريح.
كابوس مجلد المشروع المشترك
احتاج فريق تصميم وفريق تطوير إلى مشاركة الأصول في مجلد على خادم Linux: /data/project-x. وضع مدير النظام الجميع في مجموعة project-x-team وأعطى المجموعة صلاحية الكتابة على المجلد. لكن سادت الفوضى. عندما كان مصمم يرفع ملفًا، كان مملوكًا لـ designer:designers، ولم يتمكن المطورون من تعديله. وعندما أنشأ مطور مجلدًا فرعيًا، كان مملوكًا لـ dev:developers، ولم يتمكن المصممون من إضافة ملفات إليه. كان الجميع يطلبون باستمرار من مدير النظام إصلاح الصلاحيات. الحل؟ قام المسؤول بتشغيل chmod g+s /data/project-x. هذا قام بتعيين بت SGID على المجلد. ومنذ ذلك الحين، كل ملف ومجلد جديد يتم إنشاؤه داخل /data/project-x ورث تلقائيًا مجموعة project-x-team. وعاد الوئام.
الدرس: استخدام SGID على مجلد هو الطريقة الصحيحة وغير الملتوية لإدارة مجلدات المجموعات المشتركة.
الثغرة الأمنية في موقع الويب العام
أطلق مطور ويب مستقل موقع PHP بسيط لعميل. للسهولة، ترك ملف تكوين قاعدة البيانات، config.inc.php، في نفس المجلد الذي توجد به الصفحة الرئيسية. احتوى الملف على اسم مستخدم وكلمة مرور قاعدة البيانات كنص عادي. كانت صلاحياته الافتراضية 644 (-rw-r--r--)، مما يعني أن مستخدم خادم الويب يمكنه قراءته (وهذا جيد)، ولكن كذلك يمكن لأي شخص على الكوكب خمّن عنوان URL. عثر ماسح أمني على الملف، وقام المهاجم بتنزيل بيانات اعتماد قاعدة البيانات. كان يجب أن يكون الإصلاح chmod 600 config.inc.php، مما يجعله قابلاً للقراءة فقط من قبل المالك (عملية خادم الويب).
الدرس: لا تفترض أبدًا أن الصلاحيات الافتراضية آمنة. يجب تأمين الملفات الحساسة مثل ملفات التكوين والمفاتيح الخاصة لتكون مقيدة قدر الإمكان.
الأخطاء والفخاخ الشائعة
- مطرقة
chmod 777الثقيلة. عند الإحباط، يميل الكثيرون إلى تشغيلchmod -R 777 .على مجلد. هذا يعطي الجميع بشكل متكرر صلاحية القراءة والكتابة والتنفيذ لكل شيء. إنها ثغرة أمنية كارثية والمعادل الرقمي لخلع أبواب بيتك وترك لافتة "أشياء مجانية بالداخل" على العشب. لا تفعل ذلك. - نسيان صلاحية
xللمجلد. يمكن أن يكون لديك صلاحيةrعلى ملف ولكن لا يمكنك الوصول إليه لأنك لا تملك صلاحيةxعلى أحد المجلدات الأصلية في مساره. تحتاج إلى صلاحية التنفيذ على جميع المجلدات التي ترغب في عبورها. - لغز
umask. هل تساءلت يومًا لماذا تكون الملفات الجديدة التي تنشئها644وليست777؟ هذا بسببumaskالخاص بك.umaskهو "قناع" يطبقه الـ shell الخاص بك، ويزيل الصلاحيات من الملفات والمجلدات عند إنشائها.umaskشائع هو022يزيل صلاحية "الكتابة" للمجموعة والآخرين، محولًا القيمة الافتراضية666إلى644. - الاعتقاد بأن
chmod +xهو نفسchmod 755. ليس كذلك.chmod 755 my_fileيعين الصلاحيات بشكل مطلق.chmod +x my_fileيضيف بت التنفيذ لأي فئة مستخدم (المالك، المجموعة، الآخرون) لديها بالفعل بت القراءة، دون تغيير أي بتات أخرى. الوضع الرمزي نسبي؛ الوضع الثماني مطلق.
لماذا يجب أن يكون على رادارك
إذا كنت تلمس سطر أوامر غير Windows، فأنت بحاجة إلى فهم chmod. إنه ليس اختياريًا. هذه المعرفة حاسمة عندما:
- تنشر أي تطبيق على خادم Linux.
- تكتب سكريبتات (Shell, Python, Node.js) تحتاج إلى أن تكون قابلة للتنفيذ.
- تعمل مع Git، الذي لديه أفكاره الخاصة حول صلاحيات الملفات.
- تنشئ مشاركات ملفات أو بيئات عمل تعاونية.
- تقوم بتقوية أمان الخادم عن طريق تقييد الوصول إلى الملفات الحساسة.
- تستخدم Docker، حيث تكون صلاحيات الملفات داخل الحاوية ذات أهمية قصوى.
chmod هو واحد من أول وأهم الأوامر الأساسية التي تفصل المستخدم العادي عن مشغل النظام أو المطور الحقيقي. فهمه هو طقس عبور إلى التحكم في الجهاز، وليس مجرد استخدامه.
تعمق أكثر
- Wikipedia: chmod - نظرة عامة ممتازة على الأمر وتاريخه وترميزاته المختلفة.
- Wikipedia: File-system permissions - نظرة أوسع على مفاهيم DAC و ACLs والترميز الرمزي/الثماني عبر الأنظمة.
- The Linux man-pages project: chmod(1) - المرجع الفني الرسمي لأمر
chmodعلى Linux. كثيف ولكنه موثوق. - The Open Group Base Specifications (POSIX): chmod - المعيار الفعلي الذي يحدد كيف يجب أن يتصرف
chmodعلى أي نظام متوافق مع POSIX (مثل macOS و Linux). - ArchWiki: File permissions and attributes - دليل عملي جدًا ومُصان جيدًا من مجتمع Arch Linux، يغطي
chmodوchownوالسمات الخاصة.