مستخدمو لينكس والصلاحيات: chmod وchown بلا حفظ أرقام أعمى

الجواب المباشر: افهم النموذج، لا تحفظ الأرقام

كل ملف ومجلد في لينكس محكوم بثلاث فئات فقط: المالك (user)، والمجموعة (group)، والبقية (other)، ولكل فئة ثلاثة حقوق: قراءة (r=4) وكتابة (w=2) وتنفيذ (x=1). الرقم الذي تراه مثل 644 أو 755 ليس طلاسم، بل مجموع هذه الحقوق لكل فئة. الرقم الأول للمالك، والثاني للمجموعة، والثالث للبقية. فـ644 تعني: المالك يقرأ ويكتب (4+2=6)، والمجموعة تقرأ فقط (4)، والبقية تقرأ فقط (4)، وبمجرد أن تفهم أن 6 = قراءة+كتابة، و7 = قراءة+كتابة+تنفيذ، و5 = قراءة+تنفيذ، لن تحتاج لحفظ أي جدول.

القاعدة العملية التي تكفيك في 95% من الحالات: الملفات العادية 644 (نصوص، صور، صفحات)، والمجلدات والسكربتات القابلة للتنفيذ 755، والملفات السرية مثل مفاتيح SSH والإعدادات الحساسة 600. أما 777 فهي بوابة خطر حقيقية تعطي أي مستخدم على الخادم حق الكتابة والتنفيذ، ولا يوجد سبب مشروع تقريباً لاستخدامها على خادم إنتاج. في هذا المقال نبني الفهم من الأساس، ثم نمرّ على أخطاء صلاحيات مجلد storage التي تعطّل نصف تطبيقات لارافيل ولا رافيل، وننتهي بقاعدة sudo بدل تسجيل الدخول كـroot يومياً.

نموذج المالك والمجموعة والبقية

نفّذ ls -l داخل أي مجلد وستظهر سطور تبدأ بشيء مثل -rw-r--r--. الحرف الأول يخبرك بنوع العنصر: شرطة للملف العادي، وحرف d للمجلد، وحرف l للرابط الرمزي. بعده تسع خانات مقسّمة ثلاث ثلاث: أول ثلاث للمالك، ثم ثلاث للمجموعة، ثم ثلاث للبقية.

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

كيف تقرأ 750 مثلاً بسرعة

فكّها لثلاثة أرقام: 7 للمالك (4+2+1 قراءة وكتابة وتنفيذ)، 5 للمجموعة (4+0+1 قراءة وتنفيذ بلا كتابة)، 0 للبقية (لا شيء). هذه صلاحية ممتازة لمجلد يخص فريقاً واحداً وتريد إخفاءه تماماً عن بقية مستخدمي الخادم.

644 و755 و600: متى ولماذا

هذه الثلاثة تغطي عملك اليومي كله تقريباً:

• 644 للملفات العادية: المالك يعدّل، والجميع يقرأ. مناسبة لملفات HTML وCSS والصور وملفات النصوص التي يخدمها خادم الويب.
• 755 للمجلدات والسكربتات: المالك يملك كل شيء، والباقي يقرأ ويدخل. هذه الصلاحية الافتراضية لمجلدات المشروع ولأي سكربت shell تريد تشغيله.
• 600 للأسرار: المالك فقط يقرأ ويكتب، ولا أحد غيره يرى شيئاً. إلزامية لمفتاح SSH الخاص، وملف env، وأي ملف فيه كلمات مرور. لو رفعت صلاحية مفتاح SSH الخاص عن 600 فإن أمر ssh نفسه سيرفض استخدامه ويطبع تحذيراً بأن المفتاح مكشوف.

الأمر الذي تستخدمه هو chmod. مثال: chmod 644 index.html يضبط ملفاً واحداً، وchmod -R 755 public يضبط مجلداً وكل ما بداخله بشكل متكرر. انتبه أن -R القوية خطرة على المجلدات المختلطة، لأنها ستعطي الملفات نفس رقم المجلدات. الأنظف أن تفصل: صلاحية للمجلدات وأخرى للملفات، وسنعود لهذا في قسم storage.

خطر 777 الحقيقي بمثال

عندما يواجه مطور خطأ صلاحيات، أول ما يقفز لذهنه أحياناً هو chmod -R 777 ليختفي الخطأ فوراً. المشكلة أن 777 تعني أن أي عملية على الخادم، بأي مستخدم، تستطيع الكتابة والتنفيذ في هذا الملف.

تخيّل هذا السيناريو الواقعي: موقع فيه ثغرة رفع ملفات تسمح لمهاجم برفع ملف PHP خبيث إلى مجلد التحميلات. لو كان المجلد 755 ومملوكاً لمستخدم آخر، قد يفشل الرفع أو يعجز الملف عن التنفيذ. لكن لو كان المجلد 777، فالمهاجم يرفع الملف الخبيث ثم يشغّله عبر المتصفح، ومن هناك يتحرك داخل الخادم. تحوّل خطأ صلاحيات بسيط إلى اختراق كامل. القاعدة صارمة: لا 777 على خادم إنتاج أبداً. إن احتجت أن يكتب خادم الويب في مجلد، فالحل الصحيح هو ملكية المجلد لمستخدم خادم الويب وصلاحية 755 أو 775، لا فتحه للعالم كله.

chown: من يملك الملف أصلاً

الصلاحيات (chmod) تحدد ماذا يُسمح، لكن chown تحدد من المالك ومن المجموعة. الصيغة: chown user:group file. في تطبيقات الويب هذا مصدر نصف المشاكل. خادم الويب يعمل عادة تحت مستخدم مثل www-data على أوبونتو أو nginx على أنظمة أخرى. إذا كانت ملفات مشروعك مملوكة لحسابك الشخصي فقط، فلن يستطيع خادم الويب الكتابة في مجلدات السجلات والكاش.

أخطاء صلاحيات storage الشائعة

في لارافيل ولا رافيل، مجلدا storage وbootstrap/cache يحتاجان أن يكتب فيهما خادم الويب. الخطأ الأشهر هو رسالة "failed to open stream: Permission denied" لأن هذين المجلدين مملوكان لحسابك لا لمستخدم الويب. الحل الصحيح ثلاث خطوات: أولاً اضبط الملكية بـchown -R $USER:www-data storage، ثانياً اضبط صلاحية المجلدات بـfind storage -type d -exec chmod 775 {} \;، ثالثاً اضبط الملفات بـfind storage -type f -exec chmod 664 {} \;. هكذا يكتب خادم الويب عبر المجموعة، وتبقى بقية مستخدمي الخادم بلا صلاحية كتابة، بدل حل 777 الكسول الذي يفتح ثغرة.

sudo بدل root في العمل اليومي

الدخول اليومي بحساب root خطأ تشغيلي كبير. حساب root يملك كل شيء، وأي أمر خاطئ ينفّذه ينفّذ بلا سؤال. مثل rm -rf في المكان الغلط يمحو نظاماً كاملاً. البديل الصحيح هو حساب مستخدم عادي مع صلاحية sudo، فتعمل يومياً بحساب محدود، وعندما تحتاج أمراً إدارياً تسبقه بـsudo فقط. هذا يعطيك ثلاث فوائد: كل أمر إداري يُسجّل في السجلات مع اسم منفّذه، وتحتاج تأكيداً واعياً قبل كل عملية خطرة، ولو سُرقت جلستك العادية فالمهاجم لا يملك root مباشرة. على أي خادم سحابي جديد، أول ما تفعله: أنشئ مستخدماً، أضفه لمجموعة sudo، ثم أوقف دخول root عبر SSH.

البتات الخاصة: setuid وsetgid وsticky bit

خلف الأرقام الثلاثة المعتادة يوجد رقم رابع اختياري في المقدمة يحمل ثلاث صلاحيات خاصة تحلّ مشاكل حقيقية في العمل الجماعي:

• sticky bit (رقم 1): يُوضع على المجلدات المشتركة مثل /tmp، فيمنع أي مستخدم من حذف ملفات غيره حتى لو كان المجلد مفتوحاً للكتابة للجميع. تراه في ls -l كحرف t في نهاية صلاحية المجلد. صلاحية /tmp النموذجية 1777 لهذا السبب بالضبط: كتابة للجميع مع منع كل مستخدم من العبث بملفات الآخرين.
• setgid على مجلد (رقم 2): يجعل كل ملف جديد يُنشأ داخل المجلد يرث مجموعة المجلد لا مجموعة منشئه. هذه أنظف طريقة لمجلد يتشاركه فريق، فتضمن أن كل ما يُنشأ يبقى ملكاً للمجموعة المشتركة ويستطيع الجميع الكتابة فيه.
• setuid على ملف تنفيذي (رقم 4): يشغّل البرنامج بصلاحية مالكه لا بصلاحية من شغّله. قوي لكنه خطر، فبرنامج بـsetuid يملكه root يعمل بصلاحيات root لأي مستخدم يشغّله. لا تضعه إلا على ثنائيات النظام الموثوقة، وافحص دورياً وجود أي ملف setuid غير متوقع فقد يكون باب اختراق.

umask: الصلاحية الافتراضية للملفات الجديدة

لماذا يُنشأ ملفك الجديد بصلاحية 644 لا 666؟ لأن umask يطرح صلاحيات من الافتراضي. القيمة الشائعة 022 تطرح حق الكتابة عن المجموعة والبقية، فيصبح الملف 644 والمجلد 755. لو أردت أن تكون الملفات الجديدة أكثر انغلاقاً افتراضياً، اضبط umask إلى 077، فتصبح كل الملفات الجديدة 600 والمجلدات 700 مقروءة لمالكها فقط. هذا مفيد على خادم يشاركه أكثر من مستخدم وتريد خصوصية افتراضية صارمة.

خاتمة عملية

لا تحفظ أرقاماً، افهم النموذج ثم طبّق هذه القرارات:

• ملفات عادية 644، مجلدات وسكربتات 755، أسرار 600.
• لا 777 على الإنتاج مطلقاً، بدلها بملكية صحيحة عبر chown.
• مجلد storage الكتابي: ملكية لمستخدم الويب وصلاحية 775 للمجلدات و664 للملفات.
• اعمل بحساب عادي مع sudo، وأوقف دخول root عبر SSH.

لو كنت تدير تطبيقاً مخصصاً يحتاج ضبطاً دقيقاً للصلاحيات وعزلاً حقيقياً للموارد، فالبنية المناسبة خادم سحابي بموارد مخصصة لك وحدك. راجع باقات الخادم السحابي والأسعار والباقات، فباقة أساس تكفي معظم التطبيقات المتوسطة وتفعّل تلقائياً خلال ثوانٍ بعد الدفع من سيرفرات الرياض بزمن استجابة نحو 8ms.