كيفية تشغيل البرامج بصلاحيات المستخدم الجذر من مشغل النظام في لينكس

إنفورماتيك ديجيتال » لينكس » كيفية تشغيل البرامج بصلاحيات المستخدم الجذر من مشغل النظام في لينكس

في نظام ويندوز، اعتاد الكثيرون على الضغط على مفتاحي Shift+Enter أو Shift+النقر بزر الفأرة الأيسر لفتح برنامج بصلاحيات إدارية من قائمة ابدأ. أما في نظام لينكس، فالأمر ليس بهذه السهولة دائمًا، لأن الأمان يعتمد على صلاحيات المستخدم الجذر (root) و sudo وأدوات المساعدة الرسومية ، ولكل بيئة سطح مكتب أدواتها الخاصة. مع ذلك، توجد طرق بسيطة نسبيًا لتشغيل التطبيقات بصلاحيات المستخدم الجذر من مشغل التطبيقات أو اختصار أو قائمة التطبيقات، ولكن من المهم فهم ما يستلزمه ذلك.

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

ماذا يعني تشغيل شيء ما بصلاحيات المستخدم الجذر؟

في نظام لينكس، حساب المستخدم الجذر (root) هو الحساب ذو المعرّف 0 (UID 0) ويتمتع بصلاحيات غير محدودة . بإمكانه قراءة أي ملف أو تعديله أو حذفه، وتثبيت البرامج، وتغيير إعدادات النواة، والتحكم في عمليات أي مستخدم آخر. هذا يجعله أداة بالغة القوة، ولكنه في الوقت نفسه يشكل خطراً جسيماً إذا استُخدم بإهمال. خطأ إملائي بسيط في استخدام الأمر `rm` أو `mv` قد يُعطّل النظام تماماً، كما أن تشغيل برنامج نصي خبيث بصلاحيات الجذر قد يُؤدي إلى تثبيت أبواب خلفية، أو تعديل إجراءات الأمان، أو سرقة البيانات دون ترك أي أثر تقريباً.

في أوبونتو، لا يوجد كلمة مرور افتراضية لحساب الجذر، ولا يُسمح بتسجيل الدخول المباشر. تقوم فلسفة النظام على استخدام حساب المستخدم العادي، مع الاستعانة بأمر `sudo` لتنفيذ مهام محددة . يعني `sudo` تشغيل أمر ما بصلاحيات مستخدم آخر، عادةً الجذر، بعد المصادقة باستخدام كلمة مرورك الخاصة إذا كنت عضوًا في مجموعة `sudo`. هذا يحد من مدة تعرضك للاختراق، ويحفظ سجلًا يوضح من قام بأي إجراء.

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

مخاطر استخدام صلاحيات الجذر بدون حذر

من أبرز المخاطر حذف الملفات الحيوية عن طريق الخطأ . فبصفتك مستخدمًا بصلاحيات الجذر، لا توجد قيود على الأذونات؛ إذ يمكن لأمر مثل `sudo rm -rf /` مسح النظام بالكامل دون سابق إنذار. كما أنه لا يوجد عادةً سلة محذوفات لهذه الملفات المحذوفة، لذا قد يتطلب الاسترداد أدوات تحليل جنائي معقدة أو حتى إعادة تثبيت النظام بالكامل.

من المخاطر الأخرى تشغيل البرامج النصية غير الموثوقة. فإذا شغّلتَ برنامجًا تم تنزيله من أي موقع بصلاحيات مرتفعة، فأنت بذلك تمنحه صلاحيات كاملة على جهازك . حتى لو بدا البرنامج النصي غير ضار، فقد يحتوي على تعليمات تخريبية أو يُثبّت برامج ضارة بصلاحيات الجذر. لذا، يُنصح بمراجعة البرنامج، واستخدام المصادر الرسمية، والتحقق من المجموع الاختباري، واختباره في بيئة افتراضية أو حاوية قبل تشغيله في بيئة الإنتاج.

توجد أيضًا مشكلة في إمكانية التتبع. عند استخدام الأمر `sudo`، يسجل النظام الأمر، والمستخدم الذي أصدره، والوقت في `/var/log/auth.log` أو `/var/log/secure` أو `journalctl` . أما إذا سجلت الدخول مباشرةً بصلاحيات المستخدم الجذر، فسيظهر كل شيء باسم المستخدم الجذر، وستفقد القدرة على معرفة الشخص الذي أجرى كل تغيير. في بيئات تضم عدة مسؤولين أو تخضع لمعايير تدقيق مثل ISO 27001 أو PCI DSS أو غيرها، يُعدّ هذا النقص في إمكانية التتبع نقطة ضعف كبيرة.

طرق الحصول على صلاحيات من الجهاز الطرفي

الطريقة الأكثر شيوعًا والموصى بها هي استخدام الأمر `sudo` قبل تنفيذ أي أمر. على سبيل المثال، لتحديث الحزم، أو إعادة تشغيل خدمة، أو تعديل ملف محمي، سيطلب منك الأمر `sudo` كلمة مرور المستخدم، وليس كلمة مرور المستخدم الجذر، وبعد التحقق من هويتك، سينفذ الأمر بصلاحيات مرتفعة. إذا كنت ترغب في تنفيذه كمستخدم آخر، يمكنك استخدام الأمر `sudo -u username command` . وإذا نسيت استخدام `sudo`، يمكنك تكرار الأمر الأخير باستخدام `sudo !! `.

عند تنفيذ عدة مهام إدارية متتالية، قد يكون من المفيد فتح جلسة طرفية مؤقتة بصلاحيات الجذر. يُحاكي الأمر `sudo -i` تسجيل دخول كامل بصلاحيات الجذر، ويُحمّل بيئة الجذر، وينقلك إلى المجلد الرئيسي. يعمل الأمران `sudo su` و` sudo su -` أيضًا، مع أن `sudo -i` عادةً ما يكون أكثر موثوقية. للخروج من هذه الجلسة، اكتب `exit`. لا يُنصح بترك جلسة طرفية بصلاحيات الجذر مفتوحة دون مراقبة.

أما الأمر `su`، فيُبدّل المستخدم. يتبنى الأمر `su - root` أو ببساطة `su -` متغيرات بيئة المستخدم المُستهدف، بينما يحتفظ الأمر `su root` أو `su` بدون الواصلة بجزء من البيئة السابقة. يُفسّر هذا الاختلاف أخطاءً مثل `command not found`: عادةً ما توجد أوامر الإدارة في `/usr/local/sbin` و`/usr/sbin` و`/sbin`، وهي مسارات لا تظهر دائمًا في متغير PATH الخاص بالمستخدم العادي. إذا استخدمتَ `su` بدون الواصلة، فسيتعين عليك كتابة المسار الكامل أو التبديل إلى `su -` لاستخدام متغير PATH الخاص بالمستخدم الجذر.

إذا كنت ترغب في تفعيل كلمة مرور لحساب المستخدم الجذر، يمكنك فعل ذلك باستخدام الأمر `sudo passwd root` . مع أن أوبونتو لا تشجع على ذلك، إلا أنها تسمح تقنيًا بكلمة مرور لحساب الجذر. لقفل الحساب، استخدم الأمر `sudo passwd -l root` ، ولفتحه، استخدم الأمر `sudo passwd -u root`. في SSH، يتم التحكم في الوصول المباشر إلى حساب الجذر بواسطة `PermitRootLogin` في الملف `/etc/ssh/sshd_config`. من الأفضل ضبطه على `no` أو، كحد أقصى، على `prohibit-password` للسماح فقط بكلمات مرور SSH. بعد ذلك، ستحتاج إلى إعادة تشغيل خدمة SSH.

قم بضبط السترات بدقة

يُحدد ملف `/etc/sudoers` من يمكنه استخدام الأمر `sudo` ولأي غرض. يُفضل عدم تعديله يدويًا؛ فالطريقة الصحيحة هي استخدام الأمر `sudo visudo` ، الذي يُقفل الملف ويتحقق من صحة الصيغة قبل الحفظ. تأخذ القاعدة الأساسية الشكل `host user=(target_user)`. على سبيل المثال، يسمح الأمر `bob ALL=(ALL) ALL` للمستخدم `bob` بتنفيذ أي أمر بصلاحيات المستخدم الجذر على أي جهاز. كما يُمكن استخدام المجموعات، مثل `%admin ALL=(ALL) ALL`.

لمنح صلاحيات أدق، تُستخدم الأسماء المستعارة. يُصنّف `User_Alias ​​ADMINS = alice, bob` المستخدمين، ويُصنّف `Cmnd_Alias ​​LOCATE = /usr/sbin/updatedb` الأوامر. ثم يُستخدم `ADMINS ALL = LOCATE` ليتمكن هؤلاء المستخدمون من تنفيذ هذه الأوامر فقط. يمكن إنشاء أسماء مستعارة مثل `NETWORKING` لأوامر مثل `route` و`ifconfig` و`ping` و`iptables`، إلخ. يُطبّق هذا مبدأ أقل الصلاحيات دون منح صلاحيات الجذر الكاملة لأي مستخدم.

يُتيح لك خيار NOPASSWD تشغيل بعض الأوامر دون كلمة مرور، على سبيل المثال، `pi ALL=(ALL)`. NOPASSWD: ALL. هذا مفيد، ولكنه خطير في حال إساءة استخدامه. علاوة على ذلك، يتم تسجيل كل استخدام للأمر `sudo`، مما يُساعد في تدقيق الوصول واستكشاف الأخطاء وإصلاحها. في حال حدوث عطل، يُمكنك مراجعة هذه السجلات لتحديد التغيير الأخير الذي تسبب في هذا العطل.

تشغيل التطبيقات الرسومية كمسؤول من المشغل

بالنسبة للبرامج ذات الواجهة الرسومية، لا يُعد استخدام الأمر `sudo` كافيًا عادةً لعدم وجود طرفية تطلب كلمة المرور. هنا يأتي دور الأدوات الرسومية المساعدة . في بيئة KDE، يوجد الأمر `kdesu` : إذا كنت تعرف الأمر الذي يُشغّل التطبيق، يمكنك تشغيله باستخدام `kdesu that_command`. كما يتيح لك خيار "تشغيل الأمر" في قائمة KDE تشغيل تطبيق بصلاحيات مستخدم آخر بإدخال بيانات اعتماده. في بيئتي GNOME وGTK ، كان يُستخدم الأمران `gksu` و` gksudo` على نطاق واسع ؛ وهما واجهتان أماميتان للأمر `sudo` أو `su`. على سبيل المثال، يفتح الأمر `gksu synaptic` أو `gksudo gparted` التطبيق ويطلب كلمة المرور.

في الأنظمة الحديثة، يُنصح بتجنب استخدام gksu أو يُعتبر قديمًا. البديل الشائع له هو pkexec ، المبني على PolicyKit، والذي يسمح للبرامج بالعمل بصلاحيات وفقًا لسياسات محددة. تستخدم العديد من مشغلات التطبيقات الحالية pkexec للمهام الإدارية. الفكرة واحدة: لا يحتاج المستخدم إلى فتح نافذة طرفية، بل يتحقق النظام من الصلاحيات بطريقة مُحكمة.

لإنشاء اختصار في مشغل التطبيقات، عليك تعديل ملف ‎.desktop . سطر `Exec` هو المفتاح. إذا كنت ترغب في تشغيله بصلاحيات المستخدم الجذر، يمكنك استخدام أمر مثل `Exec=gksu /path/to/program` أو `Exec=kdesu /path/to/program` أو `Exec=pkexec /path/to/program`. إذا كنت تستخدم `sudo` مباشرةً، فستحتاج إلى ضبط `Terminal=true` في مشغل التطبيقات أو إعداد طلب كلمة مرور رسومي. يمكنك أيضًا تجربة الضغط على Alt+F2 وكتابة اسم المساعد واسم البرنامج، على سبيل المثال، `gksu synaptic`. في بيئة KDE، يؤدي الأمر `kdesu synaptic` أو خيار التشغيل كمستخدم آخر وظيفة مماثلة.

يوجد بديل كلاسيكي يُسمى consolehelper ، وهو غلاف لتطبيقات واجهة المستخدم الرسومية. تقوم بإنشاء رابط رمزي، على سبيل المثال، /usr/bin/xterm-root، يشير إلى /usr/sbin/consolehelper. ثم تُهيئ PAM بإنشاء /etc/pam.d/xterm-root مع تضمين بيانات المصادقة والحساب والجلسة من config-util. بعد ذلك، تُعرّف /etc/security/console.apps/xterm-root مع USER=root وPROGRAM=/usr/bin/xterm. عند تشغيل xterm-root، يطلب consolehelper مصادقة PAM ويُشغّل xterm كمسؤول النظام (root). إذا واجهت خطأ "Xlib connection to :0.0 refused by server"، فقد يُساعدك تشغيل xhost local:root.

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

أمثلة شائعة للمهام التي تتطلب صلاحيات الجذر

تتطلب العديد من العمليات اليومية صلاحيات إدارية. فإدارة الحزم باستخدام apt أو zypper أو dnf أو yum غالبًا ما تتطلب استخدام sudo. على سبيل المثال، `sudo apt update` أو `sudo apt install firefox` أو `sudo zypper install docker-ce`. وينطبق الأمر نفسه على خدمات النظام: `sudo systemctl restart apache2` أو `sudo systemctl restart ssh` أو `sudo systemctl restart nginx`. لتعديل حسابات المستخدمين، استخدم `sudo usermod`، ولتغيير ملكية الملفات، استخدم `sudo chown`. كما يتطلب تعديل الإعدادات الهامة، مثل `/etc/ssh/sshd_config`، صلاحيات المستخدم الجذر إذا تم ذلك باستخدام nano أو vim أو gedit.

لا تحتاج إلى استخدام `sudo` للأوامر التي تقرأ المعلومات فقط أو لا تُجري أي تعديلات على النظام، مثل `zypper repos` أو `systemctl status NetworkManager`. استخدام `sudo` لكل شيء بدافع العادة يُعدّ ممارسة خاطئة. الأفضل هو رفع الصلاحيات فقط عند الحاجة، ثم العودة إلى حساب المستخدم العادي في أسرع وقت ممكن.

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

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

يُنصح أيضًا بضبط صلاحيات المستخدمين ذوي صلاحيات sudo بشكل دقيق، وعدم الاعتماد كليًا على مجموعة sudo، مع الحرص على تدقيق السجلات. إذا كنت مسؤولًا عن إدارة الخوادم، فتحقق من الملفات `/var/log/auth.log` و`/var/log/secure`، أو استخدم الأمر `journalctl -xe` لاكتشاف أي إساءة استخدام. في بيئات متعددة المستخدمين، يُعدّ معرفة من نفّذ كل أمر أمرًا أساسيًا للمساءلة والامتثال للوائح الأمنية.

تفعيل وتعطيل صلاحيات الجذر باستخدام رأس الصفحة

إذا قررتَ منح صلاحيات الجذر، فعيّن كلمة مرور باستخدام الأمر `sudo passwd root`، واستخدمها فقط للمهام الضرورية، ثم أعد قفل الحساب. لتعطيل تسجيل الدخول المباشر عبر SSH، عدّل ملف `sshd_config` واضبط `PermitRootLogin no` أو `prohibit-password`، ثم أعد تشغيل SSH. لقفل الحساب محليًا، استخدم الأمر `sudo passwd -l root`. لفتحه، استخدم الأمر `sudo passwd -u root`. تُقلّل هذه الإجراءات من نقاط الضعف وتمنع هجمات التخمين العشوائي لأقوى حساب.

في معظم الحالات، الإجابة العملية على السؤال المطروح هي نعم: يمكنك تشغيل برنامج من المشغل بصلاحيات الجذر باستخدام أداة مساعدة رسومية مثل kdesu أو gksu أو gksudo أو pkexec، أو عن طريق إنشاء ملف ‎.desktop باستخدام الأمر المناسب. مع ذلك، لا يُنصح بترك هذا الإعداد مُفعّلاً لأي تطبيق. من الأفضل استخدام مشغلات إدارية مُخصصة بأسماء واضحة واستخدامها عند الضرورة فقط.

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