إدارة الصلاحيات والملكية في لينكس: دليل شامل لأوامر Chmod وChown وتفويض Sudo الآمن

تعتمد فلسفة الأمان في أنظمة لينكس على مبدأ صارم: كل كائن في النظام يُعامل كملف، ولكل ملف مالك وصلاحيات تحدد بدقة من يحق له القراءة، التعديل، أو التنفيذ. إدارة هذه الصلاحيات ليست مجرد تدبير تشغيلي يومي لمهندسي الأنظمة وDevOps، بل هي خط الدفاع الأول ضد الهجمات الخبيثة وتصعيد الامتيازات داخل السيرفرات. يفكك هذا الدليل نموذج أمان POSIX التقليدي، موضحاً الفروق الدقيقة في تطبيق أوامر chmod وchown، والأسلوب الموصى به لإدارة الامتيازات عبر sudo وحزم الإعداد المعيارية الحديثة.

نموذج الصلاحيات التأسيسي في أنظمة لينكس (POSIX Permissions)

يُقسّم نظام التشغيل أذونات الوصول لكل ملف ومجلد بين ثلاثة أطراف رئيسية: المالك (User – u)، المجموعة المالكة (Group – g)، وبقية مستخدمي النظام (Others – o). تُمنح الصلاحيات لكل فئة بناءً على ثلاثة حقوق أساسية: القراءة (Read – r)، الكتابة (Write – w)، والتنفيذ (Execute – x).

الفارق الجوهري بين صلاحيات الملفات والمجلدات

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

• صلاحية القراءة (r): على الملف، تتيح فتح المحتوى وقراءته. على المجلد، تتيح فقط استعراض أسماء الملفات داخله (مثل تنفيذ ls)، لكنها وحدها لا تتيح قراءة خصائص الملفات (أحجامها، أوقات تعديلها) أو الوصول لمحتوياتها.
• صلاحية الكتابة (w): على الملف، تتيح تعديل محتواه أو تفريغه. على المجلد، تمثل سلطة خطيرة تعني القدرة على إنشاء ملفات جديدة، أو حذف الملفات الموجودة بداخله وإعادة تسميتها، بصرف النظر عن ملكية الملف المستهدف بالحذف نفسه!
• صلاحية التنفيذ (x): على الملف، تعني إمكانية تشغيله كبرنامج تنفيذي أو سكريبت. على المجلد، تعني حق العبور (Traversal) والدخول إليه عبر الأمر cd، وقراءة البيانات الوصفية (Metadata) للملفات التي تقع في مساره. مجلد يملك المستخدم عليه صلاحية r بدون x سيسمح بعرض أسماء الملفات فقط، دون إمكانية فحص حجمها أو فتحها.

قناع الإنشاء الافتراضي (umask)

لا تنشأ الملفات والمجلدات بصلاحيات عشوائية، بل تخضع لعملية حسابية منطقية يحددها قناع المستخدم (User Mask). الوضع الافتراضي النظري في نواة لينكس هو منح الصلاحيات القصوى: 0666 للملفات (قراءة وكتابة للجميع بدون تنفيذ لأسباب أمنية)، و0777 للمجلدات (قراءة وكتابة وتنفيذ للجميع). يقوم أمر umask بطرح قيمته من هذه الحدود القصوى.

إذا كانت قيمة umask في النظام هي 0022 (وهو الشائع في خوادم الإنتاج)، فإن الملفات الجديدة تُنشأ بصلاحية 0644 (المالك يقرأ ويكتب، والمجموعة والآخرون يقرؤون فقط). أما المجلدات فتُنشأ بصلاحية 0755 (المالك يملك التحكم الكامل، والمجموعة والآخرون يدخلون ويتصفحون دون حق التعديل).

التعديل والتحكم بالصلاحيات عبر الأمر chmod

يُستخدم الأمر chmod (اختصار Change Mode) لتعديل بتات الوصول للملفات والمجلدات، ويُنفّذ عبر طريقتين أساسيتين: التمثيل الثماني (Octal Mode) والتمثيل الرمزي (Symbolic Mode).

التمثيل الثماني مقابل التمثيل الرمزي

يعتمد التمثيل الثماني على إسناد وزن رقمي ثنائي لكل صلاحية:

• القراءة (r) = 4
• الكتابة (w) = 2
• التنفيذ (x) = 1

بجمع هذه الأرقام، يتشكل رقم مكون من ثلاث خانات يمثل المالك، المجموعة، والآخرين. على سبيل المثال، الصلاحية الشهيرة chmod 755 file.sh تعني: المالك لديه 7 (4+2+1)، والمجموعة لديها 5 (4+1)، والآخرون لديهم 5 (4+1).

أما التمثيل الرمزي فيوفر دقة أكبر عند الرغبة في تعديل حق محدد دون المساس ببقية الحقوق القائمة، باستخدام المعاملات (+ للإضافة، - للسحب، = للتعيين الصريح):

• chmod u+x script.sh: منح صلاحية التنفيذ لمالك الملف فقط.
• chmod g-w,o-r secret.txt: سحب حق الكتابة من المجموعة وحق القراءة من الآخرين.
• chmod a+r document.pdf: منح حق القراءة للجميع (All).

الصلاحيات الخاصة المتقدمة (Special Bits)

يوفر نظام لينكس خانة رابعة تسبق الخانات الثلاث التقليدية للتعامل مع متطلبات أمنية وتنظيمية معقدة:

• SUID (Set User ID – القيمة الرقمية 4000): عند تفعيلها على ملف تنفيذي، يعمل البرنامج بامتيازات مالك الملف وليس بامتيازات المستخدم الذي قام بالتشغيل. أبرز مثال هو تطبيق /usr/bin/passwd؛ يحتاج المستخدم العادي لتعديل ملف /etc/shadow المحمي لتغيير كلمة مروره، فيعمل الأمر بصلاحية root مؤقتاً لإنجاز المهمة بفضل بت SUID. يُمثل رمزياً بالحرف s في خانة المالك (مثل -rwsr-xr-x).
• SGID (Set Group ID – القيمة الرقمية 2000): عند تطبيقها على المجلدات، فإن أي ملف أو مجلد فرعي يُنشأ بداخلها يرث تلقائياً المجموعة المالكة للمجلد الأب، بدلاً من المجموعة الأساسية للمستخدم الذي أنشأه. هذه الميزة جوهرية لإنشاء مساحات العمل المشتركة بين أعضاء فريق واحد. يُمثل بالحرف s في خانة المجموعة.
• Sticky Bit (القيمة الرقمية 1000): تمنع هذه الصلاحية المستخدمين من حذف أو إعادة تسمية الملفات داخل مجلد مشترك ما لم يكونوا المالكين الفعليين للملف أو مستخدم root، حتى وإن كان المجلد يملك صلاحية كتابة للجميع (777). التطبيق الأشهر هو مجلد /tmp. يُمثل بالحرف t في خانة الآخرين (مثل drwxrwxrwt).

إدارة الملكية ونقلها باستخدام الأمر chown

يتحكم الأمر chown (اختصار Change Owner) بتعيين ملكية الملفات والمجلدات لمستخدم معين أو مجموعة معينة داخل النظام. وحده المستخدم ذو الصلاحيات الجذرية (root) يمكنه نقل ملكية الملفات لمستخدم آخر، لمنع محاولات التهرب من الحصص التخزينية (Disk Quotas) أو تجاوز الرقابة الأمنية.

الصيغ المعتمدة لأمر chown

تتنوع صيغ استخدام chown لتلائم السيناريوهات التشغيلية:

• chown deployer app.log: تغيير المالك فقط إلى المستخدم deployer مع بقاء المجموعة كما هي.
• chown :developers app.log: تغيير المجموعة المالكة فقط إلى developers (وهو بديل للأمر القديم chgrp).
• chown deployer:developers app.log: تغيير المالك والمجموعة معاً في أمر واحد.

مخاطر الخيار المتكرر (Recursive Flag -R)

يؤدي تشغيل chown -R user:group /path إلى تطبيق التغيير على كل شجرة المجلدات الفرعية والملفات. يكمن الخطر التشغيلي الأكبر في تمرير مسافات خاطئة داخل المسارات، مثل كتابة chown -R user:group / var/www بطريق الخطأ بوضع مسافة بعد الجذر، مما يغير ملكية النظام بالكامل ويؤدي إلى انهيار الخادم فوراً وخروجه عن الخدمة. كما يجب الحذر من تطبيق الصلاحيات بشكل متكرر عبر الروابط الرمزية (Symlinks) دون استخدام معامل -h لتفادي تعديل الملفات الأصلية المستهدفة بالرابط خارج المجلد المعني.

تفويض الصلاحيات الآمن عبر sudo وهندسة ملفات الإعداد

تسجيل الدخول المباشر بحساب root عبر SSH أو الشل يُعد من أسوأ الممارسات الأمنية؛ فهو يلغي إمكانية تتبع الأفعال للمستخدم المسؤول، ويجعل أي خطأ طباعي كارثياً. أتى نظام sudo (Superuser Do) كحل معياري يتيح للمستخدمين تشغيل أوامر بامتيازات إدارية، مع توثيق كل عملية في سجلات النظام (Logs) وتطبيق مبدأ الحد الأدنى من الامتيازات (Least Privilege).

الممارسة المعيارية: استخدام مجلد /etc/sudoers.d/ بدلاً من الملف الرئيسي

تعتمد توزيعات الإنتاج الحديثة (مثل RHEL وUbuntu) على تنظيم قواعد الصلاحيات في ملفات مستقلة داخل مجلد /etc/sudoers.d/ بدلاً من التعديل المباشر على ملف /etc/sudoers. تضمن هذه الطريقة عدم مسح التعديلات الخاصة بالتطبيقات وفرق العمل عند تحديث حزم النظام عبر مديري الحزم، وتتيح للمهندسين إدارة القواعد عبر أنظمة الأتمتة (Ansible وPuppet) بسهولة وعزل كامل.

يشترط نظام sudo متطلباً أمنياً صارماً: يجب أن تكون صلاحية أي ملف داخل /etc/sudoers.d/ مضبوطة على 0440، وألا يحتوي اسم الملف على علامات ترقيم (مثل النقاط) وإلا تجاهله النظام تماماً.

استبدال محررات النصوص العادية بأمر sudoedit

من الأخطاء الكارثية تنفيذ أوامر مثل sudo nano /etc/hosts أو sudo vim /etc/nginx/nginx.conf. تتيح معظم محررات النصوص إمكانية تشغيل الشل الداخلي (Shell Escape) من داخل واجهة المحرر، فإذا كان المحرر نفسه يعمل تحت امتيازات root، يستطيع المستخدم فتح شل ذي صلاحيات كاملة والهروب خارج أي قيود فُرضت عليه.

الحل الآمن المعتمد هو استخدام أداة sudoedit (أو تمرير الخيار sudo -e). تعمل هذه الأداة على نسخ الملف المستهدف إلى مسار مؤقت، وتفتحه بمحرر المستخدم العادي غير المرفوع الصلاحيات، وفور حفظ الملف والخروج، يتولى sudo فحص الملف وتطبيق التعديل على الملف الأصلي بامتيازات آمنة ومنضبطة.

التحديات الأمنية المعاصرة: ثغرة CVE-2025-32463

أكدت الثغرة الأمنية الخطيرة CVE-2025-32463 (المعروفة بـ “chroot to root” والمصنفة بدرجة خطورة CVSS 9.3) أن تفويض الصلاحيات يحتاج لمتابعة مستمرة. سمحت الثغرة لمستخدمين غير مصرح لهم في ملف sudoers برفع امتيازاتهم محلياً إلى مستخدم الجذر عبر استغلال آلية تعامل الخيار --chroot في بعض إصدارات حزمة sudo. تم إغلاق هذه الثغرة في الإصدار 1.9.17p1 والإصدارات اللاحقة، مما يثبت ضرورة التحديث المستمر وعدم الاكتفاء بالضبط التكويني فقط للأمان.

تطبيق عملي: تهيئة مجلد عمل جماعي وتفويض صلاحيات خدمة محدودة

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

#!/usr/bin/env bash
# Strict error handling: exit immediately if a command fails
set -euo pipefail

# Scenario 1: Collaborative Directory with SGID and Sticky Bit
echo "[*] Configuring shared collaboration directory..."

# Create the dedicated engineering group if it does not exist
sudo groupadd -f devops

# Create the directory target
sudo mkdir -p /var/shared/devops-workspace

# Assign ownership: root owns the folder, devops group owns group rights
sudo chown root:devops /var/shared/devops-workspace

# Apply permissions:
# 3 = 2 (SGID) + 1 (Sticky Bit)
# 770 = User:rwx, Group:rwx, Others:none
sudo chmod 3770 /var/shared/devops-workspace

# Display directory metadata to verify special bits (drwxrws--t)
ls -ld /var/shared/devops-workspace

# Scenario 2: Least Privilege Sudoers Policy for Deployer
echo "[*] Configuring isolated deployment sudo policy..."

# Create system user for deployment pipelines
sudo useradd -m -s /bin/bash deployer || true

# Define rule: allow deployer to restart and check Nginx status without password
# Use tee to safely handle root redirection
echo "deployer ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx" | \
sudo tee /etc/sudoers.d/deployer-nginx > /dev/null

# Enforce strict 0440 read-only permissions required by sudo
sudo chmod 0440 /etc/sudoers.d/deployer-nginx

# Validate syntax with visudo in check mode
sudo visudo -cf /etc/sudoers.d/deployer-nginx

echo "[+] Configuration completed successfully."

شرح أسطر الكود البرمجي خطوة بخطوة

1. set -euo pipefail: تفعيل نمط المعالجة الصارم في الشل لضمان توقف السكريبت فوراً في حال فشل أي أمر، أو استخدام متغير غير معرّف، لمنع تنفيذ أوامر لاحقة على بيئة غير مستقرة.
2. sudo groupadd -f devops: إنشاء مجموعة مخصصة لمهندسي العمليات مع خيار -f لتفادي إرجاع خطأ في حال كانت المجموعة موجودة مسبقاً.
3. sudo mkdir -p /var/shared/devops-workspace: إنشاء المسار المستهدف للمجلد المشترك بالكامل متضمناً المجلدات الأبوية عند الحاجة.
4. sudo chown root:devops /var/shared/devops-workspace: جعل المستخدم root هو المالك للمجلد، بينما تنتمي الصلاحيات الجماعية إلى فريق devops.
5. sudo chmod 3770 /var/shared/devops-workspace: ضبط الصلاحيات بوضع البت 3، وهو حاصل جمع 2 (خاصية SGID التي تفرض وراثة مجموعة devops لأي ملف يُنشأ داخل المجلد) مع 1 (خاصية Sticky Bit التي تمنع أي مهندس من حذف ملفات زميله داخل المجلد المشترك). أما 770 فتحجب أي وصول للمستخدمين الخارجين عن المجموعة.
6. ls -ld /var/shared/devops-workspace: استعراض تفاصيل المجلد؛ وتظهر الصلاحيات بالنمط drwxrws--t، حيث ترمز s لوجود SGID وترمز t لوجود Sticky Bit.
7. sudo useradd -m -s /bin/bash deployer || true: إنشاء مستخدم محدد لأتمتة عمليات النشر مع إنشاء مجلد منزلي وتعيين مسار الشل الافتراضي، مع تجاوز الخطأ إن وجد الحساب مسبقاً.
8. echo "deployer ALL=(root) NOPASSWD: ..." | sudo tee /etc/sudoers.d/deployer-nginx: حقن قاعدة تفويض محددة بدقة تتيح تشغيل أمرين حصرياً عبر مسارهما الثابت والمطلق (/usr/bin/systemctl restart nginx وstatus) بدون طلب كلمة مرور. استُخدم الأمر tee تحت مظلة sudo للكتابة الآمنة في مسار النظام.
9. sudo chmod 0440 /etc/sudoers.d/deployer-nginx: فرض الصلاحية المعيارية 0440 (قراءة فقط للمالك والمجموعة)؛ سيرفض sudo قراءة الملف إن كانت صلاحياته متساهلة عن هذا الحد.
10. sudo visudo -cf /etc/sudoers.d/deployer-nginx: فحص السلامة النحوية (Syntax Validation) لقاعدة الصلاحيات الجديدة عبر محرك visudo لضمان خلوها من الأخطاء التكوينية قبل دخولها حيز التنفيذ.

الأخطاء الشائعة في إدارة الصلاحيات وكيفية تجنبها

1. فخ الصلاحية المطلقة: تطبيق chmod 777 لحل المشاكل

عند ظهور خطأ “Permission Denied” في بيئات التشغيل (مثل فشل خادم الويب في قراءة مجلد التخزين المؤقت)، يلجأ البعض سريعاً لتنفيذ chmod -R 777 كحل سريع. هذه الخطوة تمثل ثغرة مدمرة؛ فهي تمنح أي عملية أو مستخدم محلي (بما في ذلك الحسابات المخترقة لخدمات أخرى) القدرة على كتابة وتعديل وحقن أكواد خبيثة داخل ملفات التطبيق. الحل الصحيح هو تحديد المستخدم الفعلي الذي يشغّل الخدمة (مثل www-data أو nginx)، ونقل ملكية المجلدات المحددة إليه عبر chown، مع الاكتفاء بمنحه الحد الأدنى من الأذونات مثل 750 للمجلدات و640 للملفات.

2. التحرير المباشر لملف sudoers بدون أداة visudo

يؤدي فتح ملف /etc/sudoers بمحرر نصوص عادي (مثل nano) وحفظه دون تدقيق إلى كارثة؛ إذا حدث خطأ مطبعي في صياغة سطر واحد، سيتعطل محرك sudo بالكامل، مما يمنع جميع مديري النظام من استخدام صلاحيات الإدارة أو إصلاح الخطأ (Lockout) دون إعادة تشغيل الخادم في نمط الإنقاذ (Single-User Mode). القاعدة الثابتة هي تعديل الملفات دوماً عبر أمر sudo visudo، أو فحص الملفات الملحقة باستخدام sudo visudo -cf /path/to/file قبل الاعتماد.

3. فشل إعادة التوجيه مع أوامر Sudo (Redirection Pitfall)

محاولة تنفيذ أمر مثل:

sudo echo "nameserver 1.1.1.1" >> /etc/resolv.conf

ستفشل فوراً برسالة Permission Denied حتى وإن كُتبت sudo في بداية السطر. السبب التقني هو أن امتيازات sudo تُمنح لبرنامج echo فقط، بينما يتولى الشل الحالي (الذي يعمل بامتيازات المستخدم العادي غير المرفوعة) معالجة معامل إعادة التوجيه (>>)، وهو لا يملك حق الكتابة في مسار /etc/resolv.conf. الحل الهندسي السليم يتمثل في استخدام الأنبوب مع أداة tee:

echo "nameserver 1.1.1.1" | sudo tee -a /etc/resolv.conf > /dev/null

4. نزع بت التنفيذ (x) عن المجلدات بحسن نية

يرغب بعض مسؤولي النظام أحياناً في منع المستخدمين من تشغيل ملفات تنفيذية داخل مجلد معين، فيقومون بسحب صلاحية التنفيذ من المجلد بالكامل (chmod -x directory). النتيجة الحتمية ليست حظر البرامج، بل تعطيل الوصول الشامل للمجلد؛ حيث سيعجز المستخدمون عن استعراض مسار المجلد بالأمر cd، ولن يتمكنوا من قراءة تفاصيل الملفات الموجودة بداخله حتى لو امتلكوا تصريح قراءة (r). لمنع تشغيل الملفات التنفيذية في مسار ما، يُترك بت التنفيذ للمجلدات كما هو، وتُفصل نقطة التثبيت بخيار noexec على مستوى نظام الملفات (File System Mount Options).

متى تعتمد على صلاحيات POSIX القياسية ومتى تنتقل إلى البدائل؟

توفر صلاحيات POSIX التقليدية (chmod وchown وsudo) كفاءة تشغيلية ممتازة، بساطة في الفحص والتدقيق، وأداءً خفيفاً جداً على موارد النظام، وهي كافية تماماً في الخوادم أحادية الغرض، حاويات النشر (Containers)، وسيرفرات التطبيقات المعزولة حيث توجد أدوار واضحة (المالك، خادم الويب، فريق الصيانة). لا تضف تعقيدات إضافية طالما كان هيكل العمل لديك يستوعب تقسيم المستخدم/المجموعة.

في المقابل، تصبح هذه المنظومة التقليدية عاجزة عند وجود هياكل مؤسسية معقدة؛ كأن يتطلب نظام الملفات منح مستخدم ثانٍ صلاحية كتابة، ومستخدم ثالث صلاحية قراءة فقط، دون تغيير المجموعة الأساسية. في هذه الحالات المتقدمة، يجب الانتقال فوراً إلى قوائم التحكم بالوصول المتقدمة (POSIX ACLs) باستخدام أدوات setfacl وgetfacl. كما يُوصى بنقل صلاحيات الوصول والتحكم إلى طبقات إدارة الهوية المركزية مثل LDAP، أو أدوات تدوير الوصول وحسابات الخدمة المدارة (Privileged Access Management) عندما يتجاوز حجم البنية التحتية عشرات الخوادم، بدلاً من الاعتماد اليدوي على ملفات sudoers المحلية.