البحث في الموقع

إنّ التكامل المستمر (Continuous integration) سهل للغاية. نزّل خدمة الأتمتة مفتوحة المصدر Jenkins، وثبّتها، وأنشئ وظيفة، وانقر على الزر، ثم احصل على رسالة بريد إلكتروني جميلة تفيد بأن إنشاءك مكسور أو معطّل (أفترض أن إنشاءك تلقائي). بعد ذلك، أصلح الاختبارات التي لا تعمل (أفترض كذلك أن لديك اختبارات)، واحصل على رسالة بريد إلكتروني أجمل تفيد أن إنشاءك على ما يرام. بعد ذلك، غرّد حول الموضوع مدعيا أن فريقك يستخدم التكامل المستمر. ثم في غضون أسابيع قليلة، ابدأ في فلترة تنبيهات Jenkins إلى مجلدها الخاص لكي لا تستمرّ بإزعاجك. على أي حال، ليس لدى فريقك الوقت أو الرغبة لإصلاح جميع اختبارات الوحدة في كل مرة يعطّلها شخص ما. بعد كل شيء، نعلم جميعًا أن اختبارات الوحدة لا تناسب فريقًا يعمل وفق مواعيد نهائية محدّدة، أليس كذلك؟ هذا خطأ. يمكن للتكامل المستمر أن يعمل في هذه الظروف بل ويجب أن يعمل فيها. ما هو التكامل المستمر؟ في الوقت الحاضر، تُطوّر البرمجيات في فرق نعمل على تطوير فروعٍ للميزات وعزل التعديلات أثناء تطويرها. ثم ندمج الفروع في فرع رئيسي master. وبعد كل عملية دمج، يُختبر المنتج بالكامل، وتُنفّذ جميع اختبارات الوحدة والتكامل المتاحة. وهذا ما يسمى «التكامل المستمر» (continuous integration ويعرف أيضا بالاختصار "CI"). في بعض الأحيان، تفشل بعض الاختبارات. عندما يحدث ذلك، نقول إن "البناءات مكسورة". مثل هذا الفشل هو أحد الآثار الجانبية الإيجابية لمراقبة الجودة لأنه يعطي تنبيهًا بعلامة حمراء فور حدوث خطأ ما. هذه ممارسة معروفة في تطوير البرمجيات، عندما يصبح إصلاح هذا الخطأ أولوية قصوى للمتسبّب فيه وللفريق بأكمله. إذ يتوجّب إصلاح الخطأ مباشرة بعد أن يرسل خادم التكامل المستمر تنبيهًا بالعلامة الحمراء. هناك بعض الأدوات الجيدة المتاحة في السوق، والتي تُؤتمت إجراءات DevOps. بعضها مفتوح المصدر يمكنك تنزيله وتثبيته على الخوادم الخاصة بك. نذكر منها على سبيل المثال: Jenkins و Go و CruiseControl. وبعضها الآخر متاح كخدمات سحابية، مثل: Travis و Shippable و Wercker وغيرها الكثير. لماذا لم يعد التكامل المستمر صالحًا؟ إن التكامل المستمر رائعٌ، ولكن في أغلب الأحيان كلما كان الفريق أكبر (وقاعدة الشيفرة كذلك)، كلما تعطلت الإنشاءات وكلما طالت المدة لإصلاحها. لقد رأيت العديد من الأمثلة يبدأ فيها فريق يعمل بجِدٍّ بتجاهل التنبيهات الحمراء، التي يرسلها Jenkins. بعد بضعة أسابيع، يصبح الفريق ببساطة غير قادر على إصلاح جميع الأخطاء في الوقت المناسب. وهذا، في الغالب، لأن العمل له أولويات أخرى. إذ لا يفهم مالكو المنتجات أهمية "البنية النظيفة" ولا يمكن للمدراء التقنيين شراء الوقت لتثبيت اختبارات الوحدة. كما أن الشيفرة المكسورة تكون أصلا في الفرع الرئيسي master، و في معظم الحالات، تكون قد نُشرت بالفعل على الإنتاج وسُلّمت للمستخدمين النهائيين. فما الحاجة إذن لإصلاح الاختبارات إذا كان العمل قد سُلّم فعليًا؟ لا تأخذ معظم فرق التطوير تنبيهات التكامل المستمر على محمل الجد. لا تمثّل Jenkins أو Travis بالنسبة لهم سوى مجرد أدوات لطيفة لا تلعب أي دور في عملية التطوير والتسليم بأكملها. بغض النظر عن ما يقوله خادم التكامل المستمر، مازلنا نقدم ميزات جديدة للمستخدمين النهائيين. ونترك إصلاح إنشائنا إلى وقت لاحق. وهذا منطقي بالنسبة لي. ما هو الحل؟ منذ بضع سنوات، نشرت مقالًا بعنوان "منع التعارضات في مشاريع PHP الموزّعة والمرنة". اقترحت في المقالة حلولًا لهذه الإشكالات في Subversion و PHP. منذ ذلك الوقت، استخدمت هذا النهج تجريبيًا في عدد من المشاريع مفتوحة المصدر وبعض المشاريع التجارية أيضا في PHP وجافا وروبي وجافاسكريبت و Git و Subversion. في جميع الحالات، كانت تجربتي إيجابية، ولهذا السبب رأى rultor.com النور لاحقًا. لذلك، فإن الحل بسيط للغاية: احظُر على أي شخص دمج أي شيء في الفرع الرئيسي master وأنشئ سكريبتًا يمكن لأي شخص استدعاؤه. سيقوم السكريبت بعمليات الدمج والاختبار والتنفيذ. لن تكون لدى السكريبت أي استثناءات. فإذا انكسر أي فرع في اختبار واحد، سيرفض الفرع بأكمله. بمعنى آخر، يجب أن تظهر تلك العلامة الحمراء للتنبيه قبل أن تنتقل الشيفرة إلى الفرع الرئيسي master. ويجب أن يتحمّل مسؤولية الاختبارات المكسورة من تسبّب فيها. لنفترض أنّني أقوم بتطوير ميزة في فرعي الخاص. انتهيت من التطوير وكسرت بعض الاختبارات عن طريق الخطأ. يحدث ذلك، فنحن جميعا نرتكب أخطاء. ولكن لا يمكنني دمج تعديلاتي في Master. سيرفض Git ببساطة تنفيذ الأمر push لأنني لا أملك الأذونات المناسبة. كل ما يمكنني فعله هو أن أستدعي السكريبت السحري، وأطلب منه دمج فرعي الخاص. سيحاول السكريبت الدمج، ولكن قبل الدخول إلى الرئيسية، ستشغّل جميع الاختبارات. وإذا كُسِر أي منها، سيكون الرفض نتيجة حتمية. لن تُدمج التعديلات التي أجريتها وأصبح لزامًا عليّ إصلاحها قبل استدعاء السكريبت مرة أخرى. قد يؤدي هذا النهج في البداية إلى إبطاء عملية التطوير، لأن على الجميع بدء كتابة تعليمات برمجية أنظف. ولكن في النهاية، فإن هذه الطريقة تؤتي ثمارها. إنشاءات ما قبل الإقلاع تقدم بعض خوادم التكامل المستمرّ CI ميزة "إنشاءات ما قبل الإقلاع"، وهذا يعني اختبار الفروع قبل دمجها في master رئيسي. لدى Travis، على سبيل المثال، هذه الميزة المفيدة للغاية. عندما تقوم بإيداع جديد في فرع ما، يحاول Travis إنشاءه على الفور، ويُبلغ عبر طلبات الإضافة في GitHub عن أي مشاكل قد تحدث. انتبه، فإنشاءات ما قبل الإقلاع لا تندمج. دورها فقط هو التحقّق مما إذا كان فرعك الخاصّ نظيفًا. بعد الدمج، يمكن بسهولة كسر الفرع الرئيسي master. لذا، فهذه الآلية لا تضمن أنه لا أحد يستطيع الإيداع بشكل مباشر، والتسبب بكسر عن طريق الخطأ. تبقى عمليات الإنشاء قبل الإقلاع تدبيرًا وقائيًا، لكنها لا تحل المشكلة تمامًا. موقع Rultor.com من أجل البدء في العمل وفق ما هو موضح أعلاه، كل ما عليك فعله هو إلغاء أذونات الكتابة في الفرع الرئيسي master (أو ‎/trunk، في Subversion). لسوء الحظ، هذا غير ممكن في GitHub. الحل الوحيد هو العمل من خلال الفروع وطلبات السحب فقط. ما عليك سوى إزالة الجميع من قائمة المتعاونين (collaborators) وسيكون عليهم إرسال تعديلاتهم من خلال طلبات السحب. بعد ذلك، ابدأ في استخدام موقع rultor.com الذي سيساعدك على اختبار كل طلب للإضافة ودمجه ودفعه. في الأساس، Rultor هو السيناريو الذي كنا نتحدث عنه أعلاه، وهو متاح كخدمة سحابية مجانية. ترجمة -وبتصرف- للمقال Master Branch Must Be Read-Only لصاحبه Yegor Bugayenko

يجد كثير من مستخدمي لينكس والأنظمة الشبيهة بيونكس عموما مشاكل في فهم أذونات Permissions الملفات والمجلّدات. يتعلق الأمر أحيانا بترتيب أوضاع بتات القراءة، الكتابة أو التنفيذ؛ بينما تكمن الصعوبة أحيانا أخرى بفهم رموز العدّ الثمانيّ Octal أو ربما كيفية حل لغز بت setuid والبت اللاّصق Sticky bit. يتوجّه هذا المقال إلى من لم يفهم قطّ هذه الأذونات بالدرجة الأولى وإلى من يجد خلطا من حين لآخر في تفاصيلها. راجع أيضا مقال مقدّمة إلى أذونات لينكس Linux Permissions. الأساسيات نبدأ أولا بالنظر إلى مخرجات أمر ls: ls -lah -rwxr-xr-- 1 daniel consultants 5K Mar 10 06:55 scanner.rb -rwxr-xr-x 1 sarah teachers 18M Jul 30 10:07 papers.tar.bz2 ثلاث مجموعات من ثلاثة أحرف: بما أن الأمر يتعلّق هنا بملفات فستظهر عارضة - في أول كل مُخرَج (سطر) . تلي العارضة مجموعة محارف (9 بالضبط، تدخُل العوارض - في الحساب) سنصطلح على تقسيمها إلى ثلاث مجموعات فرعية متساوية (3x3). المستخدِم-المجموعة-الآخرون: نسمي المجموعات الثلاث على الترتيب المستخدِم User, U، مجموعة المستخدم Group, G والآخرين Other, O. يعني هذا أن أول مجموعة محارف (rwx في السطريْن) تتعلق بالمستخدِم مالك الملفّ، الثانية (r-x في السطريْن) تتعلّق بمجموعة المستخدمين مالكة الملفّ والثالثة (--r في السطر الأول وr-x في السطر الثاني) تعني الآخرين أي بقية المستخدمين. صاحب (مالك) الملف: يظهر في نتيجة الأمر المستخدم مالك الملف ومجموعة المستخدمين مالكة الملف كذلك، لكنك لن ترى الآخرين. يعود السبب في ذلك إلى أن أذونات الآخرين (مجموعة المحارف الأخيرة ضمن المجموعات الثلاث أعلاه) تنطبق على كل من ليس مالكَ الملف وليس ضمن مجموعة المستخدمين صاحبة الملف. الأعداد الثلاثة يرتبك بعضهم عندما يرى الأذونات مذكورة بصيغة مجموعة من ثلاثة أعداد، لكنّ الأمر ليس بهذا التعقيد. تذكّر فقط أن هذه الأعداد هي أماكن تحوي الرقم الموافق للإذن حسب الترتيب (من اليسار إلى اليمين): r (القراءة)، w (الكتابة) وx (التنفيذ). لاحظ الصورة. بالنسبة لكلّ رمز، نضربه في 1 إذا كان مذكورا في الأذونات وفي 0 إن لم يكن (تظهر عارضة مكانه)، ثم نجمع نتيجة كل ثلاثي. الأذونات على المجلدات يجب الانتباه إلى أن الأذونات على المجلدات تختلف عنها على الملفات. توحي أسماء الأذونات على الملفات بعملها: قراءة الملف (r)، الكتابة فيه أو حذفه (w) وتنفيذه (x)؛ بينما الدلالة مختلفة قليلا في المجلدات: يعني إذن القراءة على مجلد أن بإمكانك عرض المجلّد. يدلّّ إذن الكتابة أن لديك القدرة على إنشاء محتوى في المجلد أو حذفه منه. يشير إذن التنفيذ إلى أنه بالإمكان الدخول إلى المجلّد، تنفيذ أمر cd عليه مثلا. البت اللاصق، معرف المستخدم ومعرف المجموعة تمثّل هذه الخيارات الثلاثة الجزئية الأكثر تعقيدا لدى الكثيرين في أذونات لينكس. معرف المستخدم صُمِّم خيار معرّف المستخدم setuid (اختصار لـ Set user ID upon execution "اضبط معرّف المستخدم أثناء التنفيذ") لحلّ مشكل أساسي: غياب الإذن الكافي لتنفيذ بعض البرامج. كان حلّ هذا المشكل بإضافة خيار إلى الملف يقول “نفّذ هذا البرنامج وفق أذونات المستخدم الذي يملكه بغضّ النظر عن المستخدم الذي ينفّذ الملف”. ينبغي الحذر من استخدام هذا الخيار - الذي أصبح متجاوزا - إذ قد يؤدي لأخطار أمنية. إن حدث ومررت بإذن على النحو التالي فأنت أمام خيار setuid: -rwsr-xr-- 1 daniel consultants 5K Mar 10 06:55 scanner.rb لاحظ حرف s في أذونات المستخدم مالك الملف مكان إذن التنفيذ x. يشير حرف s إلى أن إذن setuid مضبوط. يظهر حرف s في المثال أعلاه صغيرا Lowercase وهو ما يعني أن خيار التنفيذ متاح أيضا لمالك الملف. إن كان خيار setuid فقط مضبوطا (بمعنى أنه لا يُتاح لمالك الملف إذن تنفيذه) فسيظهر الحرف كبيرا Uppercase هكذا S. ملحوظة: ينطبق التنبيه أعلاه بخصوص هيئة الحرف (صغير أو كبير) على جميع خيارات الأذونات الخاصة. المبدأ العام هو: إذا كان الحرف الذي يشير للإذن الخاص صغيرا فهذا يعني أن الإذن لدى المالك أيضا، أما إذا كان كبيرا فهذا يعني أنه ليس لدى المالك هذا الإذن. معرف المجموعة setguid يشبه الخيّار السابق في عمله مع فرق أنه يُطبَّق على مجموعة المستخدمين المالكة للملف بدلا من المستخدم المالك: -rwxr-Sr-x 1 bjones principals 101K Aug 16 04:01 grades.xml الفرق هنا بالمقارنة مع المثال في الفقرة السابقة هو أن حرف S يوجد ضمن أذونات المجموعة بدلا من المستخدِم. لاحِظ أيضا أن الحرف S في هذا المثال كبير وهو ما يعني أنّه ليس لدى المجموعة المالكة (principals في هذه الحالة) إذن التنفيذ ولكن عند تنفيذ المستخدِم bjones (المالك) أو مستخدم آخر ليس ضمن مجموعة principals للملف فإنّ التنفيذ سيكون بصلاحيات المجموعة المالكة. البت اللاصق يُستخدم هذا البت من أجل منع مستخدمين من التعديل على أو حذف ملفات مستخدِم أو مجموعة مستخدمين. يمكن تطبيق البت اللّاصق على ملفات عادية ولكنّه يُطبَّق أكثر على المجلّدات. نفرض مثلا أنك وضعت مجلدا تحت تصرّف مجموعة من التلاميذ ثم منحت لكل طالب مجلدا خاصا به. يمكن باستخدام البتّ اللاصق التأكد من أنه لن يكون بإمكان طالب حذفُ محتوى مجلد خاصّ بطالب آخر. يبدو البت اللاّصق كما يلي (لاحظ حرف t): drwxr-xr-t 1 alice alice 4.4K 2007-01-01 09:21 Alice التعديل على الأذونات استخدم أمر chmod لتعديل أذونات ملفّ بذكر الأذونات الجديدة التي تريد تطبيقها. يغيّر الأمر التالي أذونات مجلد الويب لتصبح 755: chmod 755 web_directory يغيّر الأمر أدناه أذونات ملف لتصبح 644: chmod 644 grocery_list.txt تعيين معرف المستخدم، معرف المجموعة والبت اللاصق يمكن استخدام أمر chmod أيضا لتعيين الأذونات الخاصّة. لتعيين معرّف المستخدم (نضيف 4 أمام الأذونات الاعتيادية): chmod 4644 script.rb يمكن أيضا استخدام طريقة إضافة الأذونات الأخرى: chmod u+s script.rb لتعيين معرّف المجموعة (نضيف 2 أمام الأذونات الاعتيادية): chmod 2644 script.rb أو: chmod g+s script.rb لتعريف البت اللّاصق (نضيف 1 أمام الأذونات الاعتيادية): chmod 1644 myfiles أو: chmod o+t myfiles ترجمة -وبتصرّف- للمقال A Unix and Linux Permissions Primer لصاحبه Daniel Miessler.

لينكس هو نظام تشغيلٍ متعدد المستخدمين مبني على مفاهيم يونكس (Unix) لملكيّة الملفّّات والأذونات (permissions) بهدفِ توفير حمايةٍ أفضل. إذا كنتَ تخطط لتحسين مهاراتك بلينكس فيجب عليك أن تمتلك فهمًا جيدًا لكيفية عمل ملكية الملفّّات والأذونات في لينكس. هناك العديد من التعقيدات عند التعامل مع ملكية الملفّّات والأذونات، لكننا سنحاول جهدنا لاستخلاص المفاهيم الأساسية المهمّة لفهم كيفية عملها سنتطرّق إلى كيفية عرض وفهم ملكية الملفّّات والأذونات في لينكس. إذا كنتَ تبحث عن دليلٍ حول كيفية تعديل الأذونات، فاطّلع على هذا الدّرس: مبادئ أذونات الملفات (File permissions) على لينكس. المتطلبات تأكّد من أنّك تفهم المفاهيم التي تم تغطيتها بالدروس السابقة في هذه السلسلة: مقدّمة إلى طرفية لينكس. أساسيات التصفّح في لينكس وإدارة الملفّّات. حول المستخدمين كما ذكرنا في المقدّمة، لينكس هو نظام متعدد المستخدمين. يجب علينا أن نفهم أساسيات مستخدمي ومجموعات نظام لينكس قبل الحديث عن ملكية الملفّّات والأذونات، لأنهما الكيانان اللذان ينطبق عليهما ملكية الملفّّات والأذونات. فلنبدأ بالحديث عن أساسيات ماهيّة المستخدمين أولًا. في لينكس، هناك نوعان من المستخدمين: مستخدمو النظام (system users) والمستخدمون العاديون (regular users)، بشكلٍ عام، مستخدمو النظام يتم استخدامهم لتشغيل العمليات غير التفاعلية (non-interactive processes) والعمليات التي تعمل بالخلفية (background processes) على النظام، بينما يتم استخدام المستخدمين العاديين لتسجيل الدخول إلى النظام وتشغيل العمليات التفاعلية. عندما تقوم بالولوج لأول مرّة إلى أيّ نظام لينكس، قد تلاحظ أن النظام يبدأ مع عدّة مستخدمين للنظام حيث يقوم هؤلاء المستخدمون بتشغيل الخدمات التي يعتمد عليها نظام التشغيل، وهذا الأمر طبيعي تمامًا. من الطرق السهلة لعرض جميع المستخدمين المتوفّرين على النظام هي عرض محتويات ملفّّ etc/passwd/. كلّ سطر في هذا الملفّّ يحتوي معلوماتٍ حول مستخدمٍ واحد، بدءً باسم المستخدم الخاص به (الاسم قبل إشارة ":” الأولى). يمكنك طباعة محتويات ملفّّ passwd عن طريق الأمر التالي: cat /etc/passwd المستخدم الجذر بالإضافة إلى النوعين السابقين للمستخدمين، هناك "المستخدم الجذر" أو ما يعرف بـSuperuser أو root user، وهو يمتلك القدرة على الكتابة فوق أي تقييدات لأذونات ملكية الملفّّات أو تعديلها. بشكلٍ آخر، هذا يعني أن المستخدم الجذر يمتلك القدرة على الوصول إلى أيّ شيءٍ على خادومه الخاص. حيث يتم استخدام هذا المستخدم لتطبيق التغييرات المتعلقة بالنظام بأكمله، ويجب إبقاء هذا المستخدم آمنًا. من الممكن أيضًا أن يتم إعداد حسابات مستخدمين آخرين تمتلك صلاحيات "المستخدم الجذر". في الواقع، من أفضل التدربيات الممكن القيام بها هو إنشاء مستخدمٍ عادي يمتلك صلاحيات sudo لإدارة مهام النظام. حول المجموعات المجموعات هي تجميعات لـ0 مستخدمين أو أكثر. ينتمي المستخدم عادةً إلى المجموعة الافتراضية ويمكن أيضًا أن يكون عضوًا في أيٍّ من المجموعات الأخرى على الخادوم. من الطرق السهلة لعرض جميع المجموعات المتوفّرة على الخادوم والأعضاء بداخلها هي الاطّلاع على ملفّّ etc/group/. لن نغطّي أساسيات إدارة المجموعات في هذا المقال، ولكن يمكنك تطبيق هذا الأمر في حال كنتَ فضوليًا عن مجموعاتك: cat /etc/group الآن صرتَ تعرف ماهيةَ المستخدمين والمجموعات، فلنتحدّث عن ملكية الملفّّات والأذونات. عرض ملكية الملفات والأذونات في لينكس، كلّ الملفّّات تعتبر مملوكة من طرف مستخدمٍ واحد ومجموعةٍ واحدة، وكلّ ملفٍّّ يمتلك أذونات الوصول الخاصة به. فلنأخذ لمحة على كيفية عرض أذونات الملفّّات وملكيّتها. الطريقة الأكثر شيوعًا لعرض أذونات ملفٍّّ ما هي باستخدام الأمر ls مع خيار السرد الطويل (long listing option)، كمثال: ls -l myfile . إذا كنتَ تريد عرض أذونات جميع الملفّّات الموجودة في مسارك الحالي، فقم باستخدام الأمر بدون أيّ معامِلات مثل: ls -l تلميح: إذا كنتَ في مسار المنزل الخاص بك وكان فارغًا، ولم تقم بإنشاء أي ملفّّات لعرضها بعد، فيمكنك متابعة العملية عن طريق سرد محتويات المسار etc/ باستخدام هذا الأمر: ls -l /etc بالأسفل تجدُ مثالًا على لقطة شاشة لِمَا يُمكن للخرج أن يكون، مع تسميات كلِّ عمودٍ من الخرج: لاحظ أنّه يتم سرد وضع كلّ ملفّّ، المالك، المجموعة والاسم الخاصّين به. باستثناء عمود وضع الملفّّ (file's mode) فإنّه من السهل فهم جميع أجزاء الخرج. للمساعدة في شرح جميع هذه الحروف والرموز، فلنقم بتقسيم عمود الوضع (Mode column) إلى مكوناته الأساسية. فهم وضع الملفات للمساعدة في فهم ما تعنيه تلك الحروف والرموز، ألقِ نظرة على هذه الصورة التوضيحية التي تشرح ماهية "الوضع" أو الـ"mode” الخاص بأول ملفٍّّ من المثال أعلاه: نوع الملفات في لينكس، هناك نوعان أساسيان من الملفّّات: عادي وخاص. يتم تحديد نوع الملفّّ عن طريق أول حرفٍ من الوضع الخاص به. في هذا الدليل سنشير إلى هذا عن طريق استخدام مصطلح "حقل نوع الملفّّ". يُمكن أن يتم التعرف على الملفّّات العادية عن طريق شَرْطَة hyphen ( - ) في حقل نوع الملفّّ الخاص بها. الملفَّّات العادية هي مجرد ملفَّّات صرّفَة تحتوي على بيانات. يتم تسميتها بالملفّّات "العادية" لتمييزها عن الملفّّات الخاصة. الملفّاّت الخاصّة هي الملفّات التي تمتلك محرف غير شَرْطَي (non-hyphen character) مثل الحروف العادية في حقل نوع الملفّ الخاصة بها، ويتم معاملتها من جانب نظام التشغيل بطريقةٍ مختلفة عن الملفّاّت المحلّية. المحرف الذي يظهر في حقل نوع الملفّ يحدّد نوع الملفّ الخاص. مثل المجلّدات (folders)، وهي الملفّاّت الخاصة الأكثر شيوعًا من بين الملفّاّت الخاصّة. يتم التعرّف على المجلّدات عن طريق محرف d الذي يظهر في حقل نوع الملفّ الخاصّ بالمجلّد (مثل لقطة الشاشة السابقة). هناك أنواعٌ أخرى من الملفّاّت الخاصّة ولكنّها ليست أساسية لِمَا سنتعلّمه هنا. أصناف الأذونات نعلمُ من الرسم البياني السابق أنّ عمود الوضع يحدد نوع الملفّّ، متبوعًا بثلاثة أصناف (classes) من الأذونات: المستخدم (المالك)، المجموعة والآخرون. ترتيب هذه الأصناف ثابت على جميع توزيعات لينكس. فلنلقِ نظرة على الأصناف التي ينتمي إليها كلّ نوعٍ من المستخدمين: المستخدم (User): مالك الملفّ (owner) ينتمي إلى هذا الصنف. المجموعة (Group): أعضاء مجموعة الملفّ ينتمون إلى هذا الصنف. الآخرون (Other): أيُّ مستخدمين آخرين ليسوا جزءًا من صنفيّ المستخدم أو المجموعة فهم ينتمون إلى هذا الصنف. قراءة الأذونات الرمزية الشيء التالي الذي من الواجب الاهتمام به هو تشكيلة المحارف الثلاثة الخاصّة بوضع الملفّ، لأنها هي التي تقوم بتحديد الأذونات الخاصّة بالملفّ، بشكلٍ رمزي (symbolic) يمتلكها كل ملفّ. يتم تمثيل أذونات الكتابة، القراءة والتنفيذ في كلِّ تشكيلةٍ ثلاثية (triad) على النحو التالي: القراءة: يتم تمثيلها بحرف r بالموقع الأول. الكتابة: يتم تمثيلها بحرف w بالموقع الثاني. التنفيذ: يتم تمثيله بحرف x بالموقع الثالث. في بعض الحالات الخاصّة، يمكن أن يكون هناك حرفٌ آخر هنا. عندما يتم وضع شَرْطَة ( - ) في أي موقعٍ من هذه المواقع، فهذا يعني الإذن المعين ذاك ليس متوفرًا لهذا الصنف. كمثال: إذا كانت التشكيلة الثلاثية للمجموعة المالكة لملفٍّ معين هي: --r ، فهذا يعني أن الملفّ هو قابل للقراءة فقط لتلك المجموعة المتصلة بالملفّ. فهم قراءة، كتابة وتنفيذ الملفات الآن صرتَ قادرًا على قراءة الأذونات الخاصّة بكلّ ملفّّ، وعلى الأرجح فإنّك الآن تريد معرفة مالذي يسمح كلّ نوعٍ من أنواع الأذونات للمستخدمين أن يفعلوا. سوف سنشرح كلّ إذنٍ بشكلٍ منفصل، ولكن عليك أن تتذكر أنّه غالبًا ما يتمُ استخدام خليط من هذه الأذونات مع بعضها البعض للسماح بوصولٍ معين إلى هذه الملفّات والمسارات من قبل المستخدمين. إليك شرحًا بسيطًا إلى نوع الوصول الذي يمنحه كلٌّ نوعٍ من الأذونات للمستخدمين. 1- القراءة يسمحُ إذن القراءة لملفٍّ عادي أن يتم عرضه من قبل المستخدم لمشاهدة محتويات الملفّ. لمجلد أو مسار، يسمح إذن القراءة لمستخدمٍ أن يقوم بعرض أسماء الملفّات الموجودة بتلك المجلدات أو المسارات. 2- الكتابة يسمحُ إذن الكتابة لملفٍّ عادي أن يتم تعديله أو حذفه من قبل المستخدم. لمجلدٍ أو مسار، يسمح إذن الكتابة بأن يتم حذف المجلد أو المسار وتعديل محتوياته (إنشاء، حذف وإعادة تسمية الملفّات الموجودة بداخله) وتعديل محتويات الملفّات التي يمكن قراءتها من قبل المستخدم. 3- التنفيذ يسمح إذن الكتابة بأن يتم تنفيذ ملفٍّ من قبل المستخدم (يجب على المستخدم أن يمتلك إذن القراءة أيضًا). أذونات التنفيذ يجب أن يتم إعطاؤها للبرامج التنفيذية وسكربتات الشلّ (shell scripts) قبل أن يتمكّن المستخدم من تشغيلها. لمجلدٍ أو لمسار، يسمح إذن التنفيذ بالوصول إلى البيانات الوصفية (metadata) الخاصة بالملفّات الموجودة بداخله (مثل الأمر cd أو ls -l). أمثلة على أوضاع الملفّات والأذونات الآن وبعدما صرتَ قادرًا على قراءة وضع الملفّات وفهم معنى إذنِ كلِ واحدٍ منها، فسوف نتطرّق إلى بضعة أمثلة لأوضاعٍ شائعة للملفّات مع شرحٍ بسيط حولها: -rw-------: تمثّل ملفًّا قابلًا للوصول فقط من قبل مالكه. -rwxr-xr-x: تمثّل ملفًّا قابلًا للتنفيذ من قبل جميع المستخدمين على النظام. -rw-rw-rw-: تمثّل ملفًّا قابلًا للتعديل من قبل جميع المستخدمين على النظام. drwxr-xr-x: تمثّل مسارًا يمكن لجميع المستخدمين على النظام الوصول إليه وقراءته. drwxrwx---: تمثّل مسارًا قابلًا للتعديل (بالإضافة إلى محتوياته) من قبل مالكه والمجموعة التي ينتمي إليها. drwxr-x---: تمثّل مسارًا يمكن الوصول إليه من قبل مجموعته. كما تلاحظ، عادةً، مالك الملفّ يتمتّع بغالب الأذونات الخاصة بالملفّ مقارنةً مع الصنفين الآخرين. عادةً، سترى أنّ صنفيّ "المجموعة" و "الآخرون" يمتلكان أذونات فرعية فقط من أذونات مالك الملفّ (مساوية لها أو أقل). هذا أمرٌ منطقي لأن الملفّات يجب أن تكون قابلة للوصول فقط من طرف المستخدمين الذين يحتاجون الوصول إليه لسببٍ معيّن. شيءٌ آخر لملاحظته هو أنّه وعلى الرغم من أنّه هناك العديد من تشكيلات الأذونات الممكنة، فإنّ عددًا محدودًا منها فقط قد يكون استخدامها منطقيًا في حالاتٍ معيّنة. كمثال فإنّ أُذنيّ الكتابة والتنفيذ غالبًا ما يتم إلحاقهما بإذن القراءة، لأنّه سيكون من الصعب تعديل، ومن المستحيل تنفيذ ملفٍّ لا تستطيع قراءته. تعديل ملكية الملفات والأذونات للإبقاء على هذا الدليل بأبسط ما يمكن، لن نتطرف إلى كيفية تعديل ملكيّة الملفّات والأذونات هنا. الخاتمة يجب أن تكون الآن قد امتلكت معرفة جيّدة حول كيفية عمل ملكيّة الملفّات والأذونات في نظام لينكس. إذا كنتَ تحبّ تعلم المزيد عن أساسيات لينكس، فمن المستحسن بشدّة أن تقوم بقراءة الدّرس القادم من هذه السّلسلة والذي سيكون حول إعادة توجيه الإدخال/الإخراج في لينكس. ترجمة -وبتصرّف- للمقال: An Introduction to Linux Permissions.

يحتاج لينكس، مثل غيره من أنظمة التشغيل متعدّدة المستخدمين Multi-user system إلى طريقة للتحكّم في وصول المستخدمين إلى مختلف الملفات. ليس من المحبّذ مثلا أن يعدّل مستخدم آخر على ملفات الإعداد التي أخذ ضبطها كثيرا من وقتك. يُطبَّق مبدأُ الفصلِ هذا على نظام تشغيل لينكس بآلية الأذونات Permissions. كيف تعمل الأذونات يُخزَّن كلّ ملف على النظام بأذوناته الخاصّة. كيف تُمثَّل؟ من الراجح أنك صادفتها أثناء عملك على نظام لينكس: drwxr-xr-x -r-w-rwrw- -rwxr--r-- تظهر الأذونات عند تنفيذ أوامر مثل ls -l. تخبر سلسلة المحارف Charcters بمعلومات الملف؛ يمكن تقسيم سلسلة المحارف الخاصّة بمعلومات الملف إلى أربعة أقسام: القسم الأول: هو المِحرف الأول الذي يدلّ على نوع الملفّ. القسم الثاني: يحوي المحارف من 2 إلى 4؛ وهي أذونات المستخدِم مالك الملف؛ أي ما يحقّ لهذا المستخدم فعله على الملف. القسم الثالث: المحارف من 5 إلى 7؛ وهي أذونات المجموعة مالكة الملف. القسم الرابع: المحارف من 8 إلى 10؛ وهي أذونات بقية المستخدمين (ليسوا مالك الملف ولا ينتمون للمجموعة مالكة الملف). يمكن للمحرف الأول أن يكون أحد المحارف التالية: - للملفات العادية. d: للمجلّدات. l: للوصلات الرمزية Symbolic link. s: لمقابس Socket يونكس. p: لأنابيب الاتّصال. c: للأجهزة الطرفيّة المحرفيّة Character device file. b: للأجهزة الطرفيّة الكتليّة Block device file. توضّح المحارف التسعة التالية لنوع الملف الأذونات في ثلاثة أقسام من ثلاثة محارف (القسم الثاني، الثالث والرابع المذكورة أعلاه): تعرض المحارف الثلاثة الأولى أذونات القراءة، الكتابة والتنفيذ بالنسبة لمالك الملف. تعرض المحارف الثلاثة الموالية نفس الأذونات ولكن بالنسبة للمجموعة مالكة الملف؛ والمحارف الثلاثة الأخيرة الأذونات بالنسبة لبقية المستخدمين. يعني المحرف الأول من كل قسم من إذن القراءة (r)، المحرف الثاني إذن الكتابة (w) والمحرف الثالث إذن التنفيذ (x). يدلّ ذكر المحرف (w، r وx) على وجود الإذن أما غياب الإذن فيُشار إليه بعارضة -. يعني وجود عارضة مكان إذن القراءة (أو الكتابة أو التنفيذ) أن المعني (المالك، المجموعة أو الآخرين) ليس لديه هذا الإذن. بالعودة إلى المثال: drwxr-xr-x يعني هذا السطر أننا أمام مجلّد (المحرف الأول d)، لدى مالك الملف (المحارف من 2 إلى 4) جميع الأذونات (rwx)، لدى المجموعة المالكة (المحارف من 5 إلى 7) إذنا القراءة والتنفيذ ولكن ليس لديها إذن الكتابة (r-x)، ونفس الشيء بالنسبة لبقية المستخدمين. تعديل الأذونات يُستخدَم أمر chmod لتعديل الأذونات. توجد طريقتان لذلك: الأولى باستخدام الأحرف المذكورة أعلاه (w، r وx)، والثانية باستخدام أرقام. سنشرح الطريقة الأخيرة هنا لأنها أسرع كثيرا. chmod 775 ~/my/file نلقي نظرة على القائمة التالية لفهم معنى الأرقام: 4 = r 2 = w 1 = w = إذن غير موجود نجمع الأرقام للحصول على الأذونات. بالنسبة لإذن rwx فيجب أن يكون 4+2+1=7؛ إذن r-x يجب أن يكون 4+0+1=5 وهكذا. بما أن لدينا ثلاثة أقسام من الأذونات (المستخدِم المالك، المجموعة المالكة وبقية المستخدمين) فسنحتاج إلى ثلاثة أرقام، رقم لكلّ قسم. أي أننا نجمع الأرقام المقابلة لأذونات كل قسم ونضعها جنبا إلى جنب في عدد من ثلاثة أرقام: الرّقم على اليسار لأذونات المستخدم المالك، الرقم في الوسط للمجموعة المالكة والرقم على اليمين لبقية المستخدمين. نعرف، بتنفيذ المبدأ أعلاه ، أن الأمر السابق يعدّل أذونات الملف /my/file/~ لتصبح كالتالي (طبقنا الأمر على ملف عادي، وبالتالي تظهر - في معلومات الملف تليها الأذونات): -rwxrwxr-x تعديل ملكية ملف يوجد أمران لتعديل ملكية الملف، الأول وهو chown يغيّر المستخدم المالك والثاني chgrp ويغيّر المجموعة المالكة. تغيير المستخدم المالك (المالك الجديد للملف /my/file/~ هو user): chown user ~/my/file تغيير المجموعة المالكة (المجموعة الجديدة هي group): chgrp group ~/my/file إن لم تكن مالكَ الملف أو تنفذ الأمرين أعلاه بصلاحيات المستخدم الأعلى root فلن ينجح تنفيذ الأمر. ترجمة -وبتصرّف- للمقال Linux File Permissions Explained لصاحبه Radek Pazdera.

أنماط حماية سامبا هنالك مستويان أمنيان متوفران لبروتوكول الشبكة «نظام ملفات الإنترنت الشائع» (Common Internet Filesystem اختصارًا CIFS) هما user-level و share-level؛ نمط الحماية المستخدم في سامبا يسمح بمرونة زائدة، موفرًا أربع طرق لاستخدام الحماية من مستوى user-level وطريقة لاستخدام share-level: النمط security=user: يتطلب من العملاء توفير اسم مستخدم وكلمة مرور للاتصال إلى المشاركات؛ حسابات المستخدمين في سامبا منفصلة عن حسابات مستخدمي النظام، لكن الحزمة libpam-smbpass ستُزامن مستخدمي النظام وكلمات مرورهم مع قاعدة بيانات مستخدمي سامبا. النمط security=domain: هذا النمط يسمح لخادوم سامبا بأن يَظهر لعملاء ويندوز كالمتحكم الرئيسي بالنطاق (Primary Domain Controller اختصارًا PDC)، أو متحكم الاحتياطي بالنطاق (Backup Domain Controller اختصارًا BDC)، أو خادوم عضو في النطاق (Domain Member Server اختصارًا DMS)، وسنشرح ذلك في الدرس القادم. النمط security=ADS: السماح لخادوم سامبا بالانضمام إلى نطاق Active Directory كعضو أصيل (native member). النمط security=server: هذا النمط تُرِك قبل أن يتمكن سامبا من أن يصبح خادومًا عضوًا، وبسبب بعض المشاكل الأمنية، فلا يجب أن يُستخدَم؛ راجع قسم «Server Security» من دليل سامبا لمزيدٍ من التفاصيل. النمط security=share: يسمح لجميع العملاء بالاتصال إلى المشاركات دون توفير اسم مستخدم وكلمة مرور. يعتمد اختيارك لنمط الحماية بالبيئة التي تعمل فيها وما الذي تريد من خادوم سامبا أن يُنجزه. النمط Security = User سيعيد هذا القسم ضبط خادوم سامبا لمشاركة الملفات والطباعة من القسمين السابقين، كي يتطلب الاستيثاق. أولًا، ثبِّت الحزمة libpam-smbpass التي ستزامن مستخدمي النظام إلى قاعدة بيانات مستخدمي سامبا: sudo apt-get install libpam-smbpass ملاحظة: لو اخترت مهمة «Samba Server» أثناء التثبيت، فستكون الحزمة libpam-smbpass مثبَّتةً مسبقًا. عدِّل الملف ‎/etc/samba/smb.conf، وعدِّل ما يلي في قسم [share]: guest ok = no في النهاية، أعد تشغيل سامبا لكي تأخذ الإعدادات الجديدة مفعولها: sudo restart smbd sudo restart nmbd سيُطلَب منك الآن إدخال اسم مستخدم وكلمة مرور عند الاتصال إلى المجلدات المشاركة أو الطابعات. ملاحظة: إذا اخترت ربط قرص شبكي للمشاركة، فعليك تفعيل الحقل «Reconnect at Logon»؛ مما يجعله يطلب اسم المستخدم وكلمة المرور مرةً واحدةً فقط، على الأقل إلى أن تُغيَّر كلمة المرور. تأمين المشاركة هنالك عدِّة خيارات متوفرة لزيادة الحماية لمشاركات المجلدات المنفصلة؛ وباستخدام مثال «[share]»، فسيشرح هذا القسم بعض الخيارات الشائعة. المجموعات تُعرِّف المجموعات تشكيلةً من الحواسيب أو المستخدمين الذي يملكون وصولًا متكررًا إلى مورد شبكي معين؛ على سبيل المثال، إذا عُرِّفت المجموعة qa وكانت تحتوي على المستخدمين freda، و danika، و rob؛ ومجموعة ثانية هي support تحتوي على المستخدمين danika، و jeremy، و vincent؛ وضُبِط مورد شبكي معيّن للسماح بالوصول إلى المجموعة qa، والذي بدوره سيمنح المستخدمين freda، و danika، و rob وصولًا لكن ليس jeremy أو vincent؛ ولما كان المستخدم danika ينتمي إلى كلي المجموعتين qa و support؛ فسيتمكن من الوصول إلى الموارد التي يُسمَح لكلا المجموعتين بالوصول إليها، بينما كل المستخدمين الباقيين سيقيدون بالموارد التي تسمح بوصول مجموعتهم إليها. يبحث سامبا عن المجموعات في النظام المحلي المُعرَّفة في ‎/etc/group ليحدد أي مستخدم ينتمي إلى أي مجموعة؛ للمزيد من المعلومات حول إضافة أو إزالة المستخدمين من المجموعات، راجع القسم «إضافة وحذف المستخدمين» من درس إدارة المستخدمين. عند تعريف المجموعات في ملف ضبط سامبا،‏ ‎/etc/samba/smb.conf؛ فإن الصيغة المتعارف عليها هي بدء اسم المجموعة بالرمز «@»؛ على سبيل المثال، إذا أردت تعريف مجموعة مسماة sysadmin في قسم محدد من ملف ‎/‎etc/samba/smb.conf، فعليك إدخال اسم المجموعة ‎@sysadmin. أذونات الملف تُعرِّف أذونات الملف الحقوق المحددة التي يملكها حاسوب أو مستخدم على مجلد أو ملف أو مجموعة ملفات؛ يمكن تعريف هذه الأذونات بتعديل الملف ‎/etc/samba/smb.conf وتحديد الأذونات لمشاركة ملف معيّن. على سبيل المثال، لو عَرَّفتَ مشاركة سامبا اسمها share وأردت إعطاء أذونات «للقراءة فقط» لمجموعة المستخدم qa؛ لكنك تريد السماح بالكتابة لمجموعة اسمها sysadmin ومستخدم اسمه vincent، فعليك تعديل الملف ‎/etc/samba/smb.conf وإضافة القيود الآتية تحت قيد [share]: read list = @qa write list = @sysadmin, vincent طريقة أخرى لضبط الأذونات في سامبا هي التصريح عن أذونات «إدارية» لمورد معيّن مُشارَك؛ حيث يمكن للمستخدمين الذي يملكون أذونات إدارية قراءة أو كتابة أو تعديل أيّة معلومات موجودة في المورد الذي أُعطي ذاك المستخدم أذوناتٍ إدارية خاصة عليه. على سبيل المثال، إذا أردت إعطاء المستخدم melissa أذوناتٍ إدارية للمشاركة share، فعليك تعديل الملف ‎/etc/samba/smb.conf وإضافة الأسطر الآتية تحت القيد [share]: admin users = melissa بعد تعديل الملف ‎/etc/samba/smb.conf، أعد تشغيل سامبا كي تأخذ التعديلات مجراها: sudo restart smbd sudo restart nmbd ملاحظة: لكي تعمل «read list» و «write list»، لا يجب أن يكون نمط حماية المستخدم في سامبا مضبوطًا إلى security = share. ضُبِط الآن سامبا ليحدد أيّة مجموعات تملك الوصول إلى مجلد مُشارَك، يجب الآن تحديث أذونات نظام الملفات. نظام أذونات لينُكس التقليدي لا يترابط جيدًا مع قوائم التحكم بالوصول في ويندوز (NT (Windows NT Access Control Lists اختصارًا ACLs؛ لحسن الحظ، توجد POSIX ACLs في خواديم أوبنتو موفرةً تحكمًا أفضل؛ على سبيل المثال، للسماح باستخدام ACLs على ‎/srv بنظام ملفات EXT3، فعدِّل الملف ‎/etc/fstab وأضف الخيار acl كما يلي: UUID=66bcdd2e-8861-4fb0-b7e4-e61c569fe17d /srv ext3 noatime,relatime,acl 0 1 ثم أعد وصل القسم: sudo mount -v -o remount /srv ملاحظة: تفترض الأوامر السابقة أن ‎/srv على قسمٍ مختلف؛ إذا كان ‎/srv، أو أي مسار آخر تختار مشاركته، هو جزء من قسم الجذر /، فربما عليك إعادة إقلاع النظام. لمطابقة ضبط سامبا، فستُعطى المجموعة sysadmin أذونات القراءة والكتابة والتنفيذ إلى ‎/srv/samba ‎/share، وستُعطى المجموعة qa إذنَيّ القراءة والتنفيذ؛ وستُملَك الملفات من المستخدم melissa. أدخِل الأوامر الآتية في الطرفية: sudo chown -R melissa /srv/samba/share/ sudo chgrp -R sysadmin /srv/samba/share/ sudo setfacl -R -m g:qa:rx /srv/samba/share/ ملاحظة: الأمر setfacl السابق يعطي أذونات التنفيذ إلى جميع الملفات في المجلد ‎/‎srv/samba/share، ربما يكون أو لا يكون هذا ما تريده. الآن من عميل ويندوز، يجب أن تلاحظ تطبيق الأذونات الجديدة للملف؛ راجع صفحات دليل acl و setfacl لمزيد من المعلومات حول POSIX ACLs. ملف ضبط سامبا لبرمجية AppArmor يأتي أوبنتو مع وحدة الحماية AppArmor، الذي يوفر تحكمًا مقيّدًا للوصول؛ ملف الضبط الافتراضي الخاص ببرمجية AppArmor لخدمة سامبا يجب أن يلائم ضبطك، للمزيد من التفاصيل حول استخدام AppArmor راجع درس AppArmor. هنالك ملفات ضبط افتراضية لكلي ‎/usr/sbin/smbd و ‎/usr/sbin/nmbd (الملفات الثنائية لعفريت سامبا) كجزءٍ من حزمة apparmor-profiles؛ أدخِل الأمر الآتي من الطرفية لتثبيت الحزمة: sudo apt-get install apparmor-profiles apparmor-utils افتراضيًا، تكون ملفات الضبط لعفريتي smbd و nmbd في وضع «البناء» مما يسمح لخدمة سامبا بالعمل دون تعديل ملف الضبط، وستُسجَّل الأخطاء فقط؛ لجعل ملف ضبط smbd في وضع «الإجبار»، ولكي يعمل سامبا كما يجب، فيجب أن يُعدَّل ملف الضبط لتضمين المجلدات التي تمت مشاركتها. عدِّل ملف ‎/etc/apparmor.d/usr.sbin.smbd مضيفًا معلومات [share]: /srv/samba/share/ r, /srv/samba/share/** rwkix, ضع الملف في وضع «الإجبار» وأعد تحميله: sudo aa-enforce /usr/sbin/smbd cat /etc/apparmor.d/usr.sbin.smbd | sudo apparmor_parser -r يجب أن تكون قادرًا على قراءة وكتابة وتنفيذ الملفات في المجلد المُشارَك كالمعتاد، لكن smbd يملك الآن حق الوصول إلى الملفات والمجلدات المضبوطة فقط؛ تأكد من إضافة القيود لكل مجلد تضبط مشاركته في سامبا؛ وستسجل أيضًا أيّة أخطاء إلى ‎/var/log/syslog. مصادر الفصل الثامن عشر من «Samba HOWTO Collection» مخصصٌ للحماية. للمزيد من المعلومات حول Samba و ACLs، راجع الصفحة «Samba ACLs». راجع أيضًا صفحة ويكي أوبنتو «Samba». ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Securing File and Printer.

إن AppArmor هو وحدة حماية في لينُكس تقيّد وصول البرامج المختلفة إلى قائمة بالملفات التابعة لها والإمكانيات المذكورة في مسودة posix 1003.le. إن AppArmor مثبَّت ومفعَّل افتراضيًا، ويستخدم «ملفات ضبط» (profiles) للتطبيقات لتحديد أيّة ملفات وأذونات يتطلبها التطبيق، بعض الحزم تُثبِّت ملفات الضبط الخاصة بها، ويمكن العثور على ملفات ضبط إضافية في حزمة apparmor-profiles. أدخل الأمر الآتي في الطرفية لتثبيت حزمة apparmor-profiles: sudo apt-get install apparmor-profilesلملفات ضبط AppArmor نمطين من التنفيذ: البناء أو التعلم (Complaining/Learning): من المسموح تجاوز ملف الضبط وستُسجَّل تلك التجاوزات؛ يفيد هذا النمط في اختبار وتطوير ملفات ضبط جديدة.الإجبار أو التقييد (Enforced/Confined): إجبار السياسة في ملفات الضبط، وتسجيل التجاوزات أيضًا. استخدام AppArmorتنويه: هذا القسم معلول بعلِّة1، فللأسف لن تعمل الأوامر التي فيه كما يجب. تحتوي حزمة apparmor-utils على أدوات سطر أوامر تمكِّنك من تغيير نمط تنفيذ AppArmor، أو معرفة حالة ملف ضبط، أو إنشاء ملفات جديدة ...إلخ. يُستخدَم الأمر apparmor_status لعرض حالة ملفات ضبط AppArmor. sudo apparmor_statusيضع الأمر aa-complain ملفَ ضبطٍ قيدَ البناء: sudo aa-complain /path/to/binالأمر aa-enforce يضعُ ملفَ ضبطٍ قيدَ التنفيذ: sudo aa-enforce /path/to/binالمجلد ‎/etc/apparmor.d هو مكان تواجد ملفات ضبط AppArmor؛ يمكن أن يُستخدَم لتعديل «نمط» جميع ملفات الضبط. أدخِل ما يلي لوضع كل الملفات في نمط البناء: sudo aa-complain /etc/apparmor.d/*لوضع جميع الملفات قيد التنفيذ: sudo aa-enforce /etc/apparmor.d/*يُستخدَم الأمر apparmor_parser لتحميل ملف ضبط إلى النواة، ويمكن أن يُستخدَم لإعادة تحميل ملف ضبط مُحمَّل مسبقًا باستخدام الخيار ‎-r؛ لتحميل ملف ضبط: cat /etc/apparmor.d/profile.name | sudo apparmor_parser -aولإعادة تحميل ملف ضبط محمَّل مسبقًا: cat /etc/apparmor.d/profile.name | sudo apparmor_parser -rيمكن استخدام ‎service apparmor لإعادة تحميل كل ملفات الضبط: sudo service apparmor reloadيمكن استخدام المجلد ‎/etc/apparmor.d/disable مع الخيار ‎‎apparmor_parser‏ ‎‎-R لتعطيل ملف ضبط: sudo ln -s /etc/apparmor.d/profile.name /etc/apparmor.d/disable/ sudo apparmor_parser -R /etc/apparmor.d/profile.nameلإعادة تفعيل ملف ضبط معطَّل، احذف الوصلة الرمزية إلى الملف في ‎/etc/apparmor.d/disable ثم أعد تحميل ملف الضبط باستخدام الخيار ‎-a: sudo rm /etc/apparmor.d/disable/profile.name cat /etc/apparmor.d/profile.name | sudo apparmor_parser -aيمكن تعطيل AppArmor، وسيزال تحميل وحدة النواة بإدخال ما يلي: sudo service apparmor stop sudo update-rc.d -f apparmor removeلإعادة تفعيل AppArmor، أدخِل: sudo service apparmor start sudo update-rc.d apparmor defaultsملاحظة: استبدل profile.name باسم ملف الضبط الذي تريد تعديله، أيضًا استبدل ‎/path/to/bin بمسار الملف التنفيذي الحقيقي؛ على سبيل المثال، للأمر ping استخدم ‎/bin/ping. ملفات الضبطملفات الضبط (profiles) هي ملفات نصية بسيطة موجودة في ‎/etc/apparmor.d/‎؛ هذه الملفات مسماةٌ وفقًا للمسار الكامل للملف التنفيذي الذي تضبطه لكن مع إبدال «‎/» بنقطة «.»؛ على سبيل المثال، ‎/etc/apparmor.d/bin.ping هو ملف ضبط AppArmor للأمر ‎/bin/ping. هنالك نوعان رئيسيان من القواعد المستخدمة في ملفات الضبط: قيود المسار (Path entries): التي تحدد الملفات التي يمكن للتطبيق الوصول إليها في نظام الملفات.قيود الإمكانيات (Capability entries): تحدد الامتيازات التي يُسمَح لعملية مقيدة بإجرائها.ألقِ نظرةً على ‎/etc/apparmor.d/bin.ping كمثال: #include <tunables/global> /bin/ping flags=(complain) { #include <abstractions/base> #include <abstractions/consoles> #include <abstractions/nameservice> capability net_raw, capability setuid, network inet raw, /bin/ping mixr, /etc/modules.conf r, }‎#include <tunables/global>‎: تضمين تعبيرات من ملفات أخرى، وهذا يسمح للعبارات المشتركة بين عدّة تطبيقات بالتواجد في ملف مشترك.(‎/bin/ping flags=(complain: المسار إلى التطبيق صاحب ملف الضبط، وضبط النمط إلى complain.capability net_raw,‎: السماح للتطبيق بالوصول إلى امتياز CAP_NET_RAW Posix.le.‎/bin/ping mixr,‎: السماح للتطبيق بوصول القراءة والتنفيذ إلى الملف.ملاحظة: يجب إعادة تحميل ملف الضبط بعد تعديله، راجع القسم «استخدام AppArmor» للتفاصيل. إنشاء ملف ضبط1. صمم خطة اختبار: فكر كيف يمكن «تمرين» التطبيق؛ يجب أن تُقسَّم خطة الاختبار إلى حالات اختبار صغيرة، وكل حالة اختبار لها شرح صغير وقائمة بالخطوات التي يجب اتباعها. بعض حالات الاختبار القياسية هي: بدء تشغيل البرنامج.إيقاف البرنامج.إعادة تحميل البرنامج.اختبار جميع الأوامر المدعومة من سكربت init.2. توليد ملف الضبط الجديد: استخدم aa-genprof لتوليد ملف ضبط جديد؛ من الطرفية: sudo aa-genprof exectableعلى سبيل المثال: sudo aa-genprof slapd3. لكي يُضمَّن ملف الضبط الجديد الخاص بك في حزمة apparmor-profiles، فبلِّغ عن علة في Lanuchpad2 عن حزمة AppArmor: ضمِّن خطة الاختبار وحالات الاختبار.أضف ملف الضبط الجديد إلى العلة.تحديث ملفات الضبطعندما لا يعمل برنامج ما كما يجب؛ فافحص الرسائل التي تُرسَل إلى ملفات السجل؛ يمكن أن يُستخدَم البرنامج aa-logprof لفحص ملفات السجل لرسائل التدقيق الخاصة ببرنامج AppArmor؛ راجعها وحدِّث ملفات الضبط. sudo aa-logprofمصادرراجع «AppArmor Administraion Guide» لإعدادات الضبط المتقدمة.للتفاصيل حول استخدام AppArmor مع إصدارات أخرى من أوبنتو، فراجع صفحة ويكي المجتمع حول AppArmor.صفحة «OpenSUSE AppArmor» هي تقديم آخر إلى AppArmor.مكان رائع للسؤال حول المساعدة في AppArmor، والاندماج مع مجتمع خواديم أوبنتو هو قناة ‎ ‎#ubuntu-server على خادوم Freenode (شبكة IRC).ترجمة -وبتصرف- للمقال Ubuntu Server Guide: AppArmor.

يشكّل ضبط إعدادات المستخدمين والمجموعات في لينكس واحدًا من المهارات الأساسية لإدارة نظام التشغيل، ويتضمن ذلك مراقبة تسجيلات الدخول الممكنة لكافة مكونات النظام. نستعرض في هذا الدرس المعلومات الأساسية عن إدارة المستخدمين وتسجيلات الدخول، سنطبق أمثلتنا على توزيعة Ubuntu 14.04 إلا أنه يمكنك بالتأكيد المتابعة مهما كانت التوزيعة التي تستخدمها. استعراض المستخدمين الحاليينتخزّن أسماء ومعلومات جميع مستخدمي نظام لينكس ضمن ملف etc/passwd/ سواءً أكانت تشير إلى مستخدمين حقيقيين (مثلي ومثلك) أو مرتبطة بتشغيل إحدى الخدمات أو وظائف النظام. يتضمن الملف etc/passwd/ معلومات حول المستخدمين المنشأين على نظام التشغيل موزعة على عدّة أسطر، بحيث يُخصّص سطر لكل مستخدم، لنلقِ الآن نظرة على محتويات الملف: less /etc/passwdroot:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh … ينقسم كل سطر من الأسطر السابقة إلى عدّة خانات يفصل بينها علامة النقطتين (:)، وما يهمنا من هذه الخانات حاليًا هي الخانة الأولى والتي تعبّر عن الاسم الفريد لكل مستخدم، كما يمكن من خلال الأمر التالي الحصول على القائمة السابقة مُضمّنة بأسماء المستخدمين فحسب: cut -d : -f 1 /etc/passwdroot daemon bin sys sync games … وكما ترى حصلنا في هذه المرة على أسماء المستخدمين فقط، السطر الأول مثلًا يحوي اسم المستخدم الإداري ذي الصلاحيات المطلقة root، كما ستجد في القائمة اسم المستخدم الخاص بك، وبين هذا وذاك هناك عددٌ آخر من المستخدمين قد لا تكون مُلِمًا بوظائفهم، مثل المستخدم dbus والذي يُشغّل بواسطة خدمة dbus، أو polkitd المسؤول عن خدمة polkit، وهكذا.. ففي لينكس يتم فصل صلاحيات المهام كلًّا على حدى، وبهذه الطريقة نضمن ألّا تنتقل أيّة مشاكل محتملة في خدمة ما إلى سائر مكونات النظام. استعراض المجموعات الحاليةتخزّن أسماء المجموعات وبعض المعلومات عنها في ملف etc/group/، والذي يمكننا استعراض محتوياته بالأمر التالي: less /etc/grouproot:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4: tty:x:5: disk:x:6: … وكما ترى فإن معظم الأسماء هنا ورد ذكرها في قائمة "المستخدمين الحاليين" منذ قليل، وهذا يدفعنا للتساؤل؛ لمَ؟ يعود السبب في ذلك إلى ما يسمى بـ"مجموعات المستخدم الخاصة" user private group أو UPG، وهو أسلوب في الإدارة والإعداد يسهّل إدارة المجموعات في لينكس، بحيث تنشئ مجموعة خاصة بكل مستخدم تتم إضافته، وتحمل هذه المجموعة ذات اسم المستخدم، وتُعيّن لتكون مجموعته الرئيسيّة، ويكون هو عضوها الوحيد، وحينها يغيّر قناع الطرح لـ umask من 022 إلى 002. ماذا يعني ذلك؟ تسمح هذه العملية بمزيد من المرونة في حالة عمل فريق ما ضمن مشروع، فبدلًا من أن تعود ملكية كل ملف يتم إنشاؤه في المشروع إلى الشخص المُنشئ، تنسد ملكية الملفات في هذه الحالة إلى ذات المجموعة المالكة للمجلد الأب، مما يسهل عملية التشارك. يتم ذلك عبر صلاحية تسمى setgid، إلا أنّ ذلك كلّه خارج نطاق موضوعنا اليوم. هنا أيضًا يمكن عرض أسماء المجموعات فقط من مجمل محتويات الملف etc/group/ عبر الأمر: cut -d : -f 1 /etc/grouproot daemon bin sys adm tty disk … معرفة المستخدم المُسجّل حاليًايتيح الأمر w في لينكس معرفة المستخدم النشط حاليًا على نظام التشغيل بالإضافة إلى مجموعة من المعلومات المهمة عنه، مثل توقيت تسجيل الدخول والأمر المستخدم حاليًا: w19:37:15 up 5:48, 2 users, load average: 0.33, 0.10, 0.07 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/0 rrcs-72-43-115-1 19:15 38.00s 0.33s 0.33s -bash demoer pts/1 rrcs-72-43-115-1 19:37 0.00s 0.47s 0.00s w إضافة للأمر w تعرض التعليمة who معلومات أكثر اختصارًا، تتضمن اسم المستخدم النشط وتوقيت دخوله فقط: root pts/0 2013-09-05 19:15 (rrcs-72-43-115-186.nyc.biz.rr.com) demoer pts/1 2013-09-05 19:37 (rrcs-72-43-115-186.nyc.biz.rr.com) تقييد تسجيلات دخول المستخدمينتقييد تسجيلات الدخول باستخدام etc/passwd/يمكن من خلال التعديل على ملف etc/passwd/ تقييد تسجيل دخول أحد المستخدمين عن طريق إسناد قيمة معينة للصدفة shell المحدّدة له، لنفترض أنه لدينا مستخدم مسجّل بالاسم "messagebus" ضمن ملف etc/passwd/: less /etc/passwd | grep messagebus messagebus:x:102:104::/var/run/dbus:/bin/false قيمة الحقل الأخير في الخرج السابق تعبّر عن الأمر الذي يتم تنفيذه عقب تسجيل الدخول بنجاح، وهي في مثالنا هنا bin/false/. فإذا حاولت تسجيل دخول المستخدم messagebus كمستخدم جذر root فستلاحظ عدم نجاح المحاولة، وفشل التحويل إلى المستخدم الجديد: sudo su messagebus لنحاول الآن تسجيل الدخول بواسطة المستخدم sshd: sudo su sshd This account is currently not available.حصلنا على الرسالة السابقة بسبب قيمة الصدفة shell المستخدمة لـ ssh وهي usr/sbin/nologin/. less /etc/passwd | grep sshd sshd:x:103:65534::/var/run/sshd:/usr/sbin/nologin أظن أنك قد عرفت الآن كيف نمنع دخول أحد المستخدمين بواسطة هذه الطريقة؟ ببساطة سنستخدم الأداة usermod لتغيير قيمة الصدفة shell من إحدى قيمها المسموحة إلى أخرى وهمية: sudo usermod -s /usr/sbin/nologin usernameتقييد تسجيلات الدخول باستخدام etc/shadow/يتيح التعديل على ملف etc/shadow/ طريقة أخرى مشابهة لتقييد تسجيلات الدخول، وهو ملف يضم كلمات سر مستخدمي النظام بشكل مشفّر، ولاستعراض محتوياته يمكننا كتابة الأمر التالي في الطرفية: sudo less /etc/shadowroot:6r79Dod3Y$3hi3QklpGEQMxwQGEss4ueNNPkoUrqUe3SwyAacaxl.Lmgq1r9i4mTblV1z6NfKMNXH1Cpnq.4iKhOiQd7Riy1:15953:0:99999:7::: daemon:*:15455:0:99999:7::: bin:*:15455:0:99999:7::: sys:*:15455:0:99999:7::: sync:*:15455:0:99999:7::: games:*:15455:0:99999:7::: man:*:15455:0:99999:7::: …يُعرَض الخرج السابق على عدّة أسطر، بحيث يُخصّص سطر لكل مستخدم، ويضم كل سطر اسم المستخدم في الخانة الأولى، وكلمة السر بشكل مشفّر في الخانة الثانية "6r79Dod3Y#3…" مسبوقة بإشارة ($)، أما الخانات التي تبدأ بعلامة النجمة (*) ولا تتلوها قيمة مشفرة من المحارف فهي تخصّ المستخدمين المتعلقين بإدارة خدمات النظام، والتي لا تملك كلمات مرور، ولا يمكنها تسجيل الدخول كمستخدم عادي. يمكننا تعطيل خانة كلمة المرور لأحد الحسابات بوضع إشارة التعجب(!) أمام قيمتها المشفّرة (تسمى هذه العملية بقفل الحساب)، ولإجراء ذلك يمكننا الاستعانة بواحدة من الأداتين التاليتين: أولًا الأمر passwd والذي يتيح قفل حساب مستخدم ما بواسطة الخيار "l-" أو إلغاء قفله مع الخيار"u-": sudo passwd -l username sudo less /etc/shadow | grep username username:!$6$vpNJ3oFe$5GSh2aU2BDcpdjvQeNFzh0zTgyRUl26x4dn77mFE/vaoXwd19m7okX44jO8TWaVqNRL8vUVTAcZVmgUT8dR.4.:15953:0:99999:7:::وكما ترى فإن كلمة المرور تبقى موجودة ضمن الملف بقيمتها المشفرة إلا أنها غير فعّالة بسبب وجود إشارة التعجب (!) أمامها. ولإلغاء قفل الحساب مجددًا يمكننا كتابة: sudo passwd -u username بِذَات الطريقة يمكن استخدام الأمر usermod لقفل أو إلغاء قفل حسابات المستخدمين وفق الخيارات "L-" و "U-" على الترتيب: sudo usermod -L username sudo usermod -U username يجب الانتباه هنا إلى أن هذه الطريقة في القفل تعمل مع حسابات المستخدمين العاديين أي تلك التي تستخدم كلمة مرور لتوثيق دخولها، بينما لا تعمل مع حسابات المستخدمين الخاصة بخدمات النظام (ممن لا تملك كلمة مرور). تقييد تسجيلات الدخول باستخدام etc/nologin/في بعض الحالات الحرجة قد تحتاج لتعطيل تسجيلات دخول كافة المستخدمين باستثناء المستخدم الجذر root، مثل حالات الصيانة الشاملة، أو فيما لو تعرض أحد تلك الحسابات لاختراق أمني. عمومًا، يمكن إنجاز ذلك ببساطة، عن طريق إنشاء ملف فارغ باسم etc/nologin/: sudo touch /etc/nologin بهذه الطريقة تمنع كافة تسجيلات الدخول للنظام باستثناء من يملك امتيازات المستخدم الجذر، حيث تتم إعادة المستخدمين إلى الصدفة المحليّة local shell أو إخبارهم بأن التوثيق خاطئ! ولإضافة بعض التوضيح يجب ألا يترك الملف السابق فارغًا، بحيث تطبع عبارة على الشاشة تقدّم بعض الشرح: sudo sh -c 'echo "Planned maintenance. Log in capabilities will be restored at 1545 UTC" > /etc/nologin' لنقوم بتجربة جديدة الآن لاختبار ما سبق: ssh user@host user@host's password: Planned maintenance. Log in capabilities will be restored at 1545 UTC Connection closed by host عند الانتهاء من التعامل مع الوضع الحرج يمكن إعادة كل شيء على حاله بحذف الملف السابق etc/nologin/: sudo rm /etc/nologinمراقبة تسجيلات الدخولبعد ضبط مختلف الإعدادات المتعلقة بالمستخدمين والمجموعات لديك، نأتي الآن إلى مهارة أخرى أساسية تتعلق بمراقبة النظام، إذ تحتفظ أنظمة لينكس الحديثة بسجلات لكافة محاولات تسجيل الدخول في ملف مستقل يخزّن على المسار var/log/auth.log/: sudo less /var/log/auth.logMay 3 18:20:45 localhost sshd[585]: Server listening on 0.0.0.0 port 22. May 3 18:20:45 localhost sshd[585]: Server listening on :: port 22. May 3 18:23:56 localhost login[673]: pam_unix(login:session): session opened fo r user root by LOGIN(uid=0) May 3 18:23:56 localhost login[714]: ROOT LOGIN on ‘/dev/tty1’ Sep 5 13:49:07 localhost sshd[358]: Received signal 15; terminating. Sep 5 13:49:07 localhost sshd[565]: Server listening on 0.0.0.0 port 22. Sep 5 13:49:07 localhost sshd[565]: Server listening on :: port 22 … باستخدام الأمر lastيتيح لنا الأمر last استعراض تسجيلات الدخول الأخيرة لنظام التشغيل موزعة على جدول: lastdemoer pts/1 rrcs-72-43-115-1 Thu Sep 5 19:37 still logged in root pts/1 rrcs-72-43-115-1 Thu Sep 5 19:37 - 19:37 (00:00) root pts/0 rrcs-72-43-115-1 Thu Sep 5 19:15 still logged in root pts/0 rrcs-72-43-115-1 Thu Sep 5 18:35 - 18:44 (00:08) root pts/0 rrcs-72-43-115-1 Thu Sep 5 18:20 - 18:20 (00:00) demoer pts/0 rrcs-72-43-115-1 Thu Sep 5 18:19 - 18:19 (00:00)يُستمد الخرج السابق من الملف etc/log/wtmp/. وكما نرى فإن السطرين الأول والثالث يوضحان لنا بأن المستخدم لا يزال قيد الدخول logged in، أما في باقي الأسطر فيعرض توقيت كل جلسة والزمن المستغرق فيها. باستخدام الأمر lastlogإذا رغبت باستعراض السجّل السابق من زاوية أخرى، فيمكنك مشاهدة توقيت آخر مرة سجّل بها مستخدمو النظام دخولهم وذلك عبر الأمر lastlog والذي يعرض لنا محتويات الملف etc/log/lastlog/ مرتبة وفقًا لمدخلات الملف etc/passwd/: lastlogUsername Port From Latest root pts/1 rrcs-72-43-115-1 Thu Sep 5 19:37:02 +0000 2013 daemon **Never logged in** bin **Never logged in** sys **Never logged in** sync **Never logged in** games **Never logged in** …كما ترى يعرض الخرج السابق تاريخ آخر تسجيل دخول لكل مستخدم، بينما تُعرض العبارة "Never logged in" أمام المستخدمين الذين يتم إنشاؤهم لإدارة خدمات النظام، والذين لا يملكون كلمات مرور كما مرّ معنا. خاتمةإنه لمن المهم أن نعلم أين يحتفظ النظام بالمعلومات المتعلقة بتسجيلات الدخول، وذلك بهدف مراقبة التغييرات التي قد تشك بأمرها، لتعطيل تسجيل الدخول عن بعض أو كل المستخدمين. ترجمة -وبتصرف- للمقال Configuring and Managing Users and Groups لصاحبه Justin Ellingwood.

تتيح الأذونات في لينكس لمالك ملف أو مجلد ما من حصر الوصول لهذا الملف أو المجلّد بناءً على الصلاحيات المرتبطة به، وهذا ما يسمح بتعدّد حقيقي للمستخدمين في لينكس حيث يمتلك كلّا منهم مستويات مختلفة من التحكّم لحماية ملفاته. يُحدّد الأمر umask الأذونات الافتراضية للملفات التي ينشئها كل مستخدم على حدى، كما يتيح إمكانية تعديل هذه الأذونات لاحقًا لضمان حماية عالية للملفات، أو لتوسيع الأذونات بغرض مشاركة الملفات مع الآخرين، اعتمادًا على احتياجاتك الخاصة ومتطلبات النظام. نتناول في هذا الدليل أساسيات التعامل مع الأذونات في لينكس، بحيث ترى فوائد إعداد umask بشكل صحيح، كما سنتكلم باختصار عن الأمر chmod باعتباره أحد أشهر الأدوات المرتبطة بإدارة الأذونات. فئات المستخدمينبالنسبة للقادمين من Windows قد تبدو مسألة الأذونات في لينكس غامضة بعض الشيء، إلا أنه حالما تتعرف على الطريقة التي نرمّز بها للأذونات فسيغدو كلّ شيء واضحًا تمامًا، وستتمكن من التعديل بسهولة على تصاريح الملفات والمجلدات. فئة المالكصُمم لينكس ليسمح بتعدّدٍ حقيقي للمستخدمين، وهذا يعني أن كلّ ملف مملوك من قبل مستخدم واحد فقط، وحتى لو كنتَ المستخدم الوحيد لحاسبك أو خادومك الخاص، فإنه لا يزال هناك عدد آخر من المستخدمين المُنشئين مسبقًا بغرض تشغيل برامج أو خدمات معينة، ويمكنك بطباعة الأمر التالي الحصول على قائمة بأسمائهم: cat /etc/passwdroot:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh lp:x:7:7:lp:/var/spool/lpd:/bin/sh mail:x:8:8:mail:/var/mail:/bin/sh news:x:9:9:news:/var/spool/news:/bin/sh uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh . . .يعرض الخرج السابق محتويات ملف etc/passwd/ وهي عبارة عن معلومات المستخدمين المنشئين على نظام تشغيلك؛ موزعةً على عدّة أسطر (سطر لكل مستخدم)، حيث تضم الخانة الأولى من كل سطر الاسم المميز لكل مستخدم، والذي غالبًا ما يرتبط بخدمات وتطبيقات مختلفة. إذ تنشئ بعض البرامج عادةً اسم مستخدم مستقل بحيث تدار جميع الخدمات المتعلقة بها من خلاله، مما يعطينا قدرة على التحكم بالوصول لهذه الخدمات. فئة المجموعة المالكةإضافة إلى فئة المالكين يمكن إسناد الأذونات إلى "مجموعة المالك" لملف أو مجلّد معيّن، وكما ذكرنا مع فئة المالك، لا يمكن أن تعود ملكية الملف سوى لمجموعة واحدة فقط، بينما يمكن لأي مستخدم أن ينضم لأكثر من مجموعة، وأن تضم كل مجموعة عدّة أعضاء أو مستخدمين. لمعرفة المجموعات التي ينتمي لها مستخدمك الحالي، اطبع الأمر: groups سيعرض الخرج أسماء المجموعات التي سبق لمستخدمك الانضمام لها، وبشكل افتراضي ينتمي أي مستخدم لمجموعة واحدة على الأقل (والتي تسمى باسمه وتعتبر مجموعته الخاصة)، إضافة إلى مجموعة أخرى. بينما يمكن استعراض جميع المجموعات المنشأة على نظامك الحالي من خلال الأمر: cat /etc/group root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4: tty:x:5: disk:x:6: lp:x:7: . . .يطبع الأمر السابق محتويات الملف etc/group/ على الشاشة، وهو يتألف من عدّة أسطر، يمثّل كلّ واحدٍ منها مجموعة ما، ويحمل الحقل الأول من كل سطر اسم المجموعة. وباعتبار أنه لا يمكن امتلاك الملف سوى من قبل مستخدم وحيد، ولتسهيل عملية المشاركة يتيح لينكس إمكانية إعطاء صلاحيات مخصصة لمجموعة من المستخدمين، تسمى هذه المجموعة بالمجموعة المالكة للملف. فئة الآخرينأخيرًا يمكن إعطاء صلاحيات الملفات في لينكس إلى فئة ثالثة تسمى "الآخرين"، ونقول عن مستخدم ما أنه ينتمي لتصنيف الآخرين، إذا لم يكن مالكًا للملف وليس عضوًا في مجموعة المالكين له. يتيح لك هذا التصنيف إمكانية وضع الأذونات العامة المتاحة لمن هم خارج التصنيفين السابقين (المالك، والمجموعة المالكة). أنواع الأذوناتيمكن لكل فئة من الفئات الثلاث السابقة (المالك، المجموعة المالكة، والآخرين) الحصول (أو عدم الحصول) على واحدة أو أكثر من الصلاحيات التالية: القراءة، الكتابة، والتنفيذ. بالنسبة للملف، فإن صلاحية القراءة تعني إمكانية استعراض محتوى الملف، وصلاحية الكتابة ترتبط بالقدرة على التعديل عليه (بما في ذلك حذفه)، بينما تعني صلاحية التنفيذ القدرة على تشغيل الملف فيما لو كان نصًا تنفيذًا script أو برنامجًا. أما فيما يتعلق بالمجلدات، تمنح صلاحية القراءة إمكانية الاستعلام ls عن محتويات المجلد (من ملفات ومجلدات)، أما صلاحية الكتابة فتسمح بتعديل محتوياته، وصلاحية التنفيذ تسمح بالدخول إلى المجلد cd والتعديل عليه. تُمثّل الصلاحيات في لينكس بطريقتين، تدعى الأولى بالترميز الأبجدي ويستخدم فيها الأحرف، بينما تسمى الأخرى بالترميز العددي (الثُماني) وتستخدم فيها الأرقام. الترميز الأبجدييمتاز الترميز الأبجدي للصلاحيات بأنه أقرب للفهم وأسهل في الاستخدام كما أنه مستعمل من قبل عدّة برامج شائعة لإدارة الأذونات في لينكس، حيث يرمّز لكل واحدة من الصلاحيات بحرفٍ واحد: صلاحية القراءة تأخذ الحرف r.صلاحية الكتابة تأخذ الحرف w.صلاحية التنفيذ تأخذ الحرف x.ويجب الانتباه هنا إلى أن الصلاحيات في لينكس تُحدّد دومًا وفق هذا الترتيب. لإسناد صلاحية معينة لملف ما يتم استخدام الحرف المقابل لها، أما لمنع الصلاحية عن الملف فنستخدم الشرطة (-)، ويتم إعطاء الصلاحية عبر تمرير ثلاث مجموعات من القيم بشكل متتابع، تحدّد الأولى صلاحية المالك، وتحدّد الثانية صلاحية المجموعة المالكة، بينما تحدّد الأخيرة صلاحية الآخرين. يُرجع الأمر ls مع الخيار l- قائمة بمحتويات المجلد الحالي مزودةً بعمود يعرض صلاحيات كل منها بالأسلوب الأبجدي: cd /etc ls -l drwxr-xr-x 3 root root 4096 Apr 26 2012 acpi -rw-r--r-- 1 root root 2981 Apr 26 2012 adduser.conf drwxr-xr-x 2 root root 4096 Jul 5 20:53 alternatives -rw-r--r-- 1 root root 395 Jun 20 2010 anacrontab drwxr-xr-x 3 root root 4096 Apr 26 2012 apm drwxr-xr-x 3 root root 4096 Apr 26 2012 apparmor drwxr-xr-x 5 root root 4096 Jul 5 20:52 apparmor.d drwxr-xr-x 6 root root 4096 Apr 26 2012 apt …وكما نرى فإن العمود الأول من اليسار يعرض أذونات الملفات والمجلدات بالترميز الأبجدي ضمن خانة مؤلفة من عشرة محارف، يحدّد الأوّل منها نوع الملف حيث يعطي الشرطة (-) للملفات، حرف (d) للمجلدات، وحرف (l) للروابط... الخ، بينما تُحدّد المحارف التسعة المتبقية صلاحيات الفئات الثلاث (المالك، المجموعة المالكة، والآخرين) من إمكانية قراءة، كتابة، وتنفيذ. لنقرأ أذونات السطر الأول من الخرج السابق مجددًا، الحرف d يرمز إلى أن acpi هو مجلد وليس ملف، يمنح مالكه الصلاحيات الثلاث (قراءة، كتابة، وتنفيذ)، في حين تمنح كلا من المجموعة المالكة وفئة الآخرين صلاحيتا القراءة والتنفيذ فقط. بينما تحدّد الشرطة (-) من أذونات السطر الرابع أن anacrontab هو ملف وليس مجلد، يمنح لمالكه صلاحيات القراءة والكتابة، أما المجموعة المالكة وفئة الآخرين فتمنح صلاحية القراءة فقط. الترميز العددي (الثماني)يعطي الترميز العددي طريقة أكثر إيجازًا لكن أقل بداهةً في التعامل مع الصلاحيات، وفق هذا الأسلوب تُحدّد صلاحيات كل فئة من الفئات الثلاث (المالك، المجموعة المالكة، والآخرين) برقم ضمن المجال بين 0 و 7. لمعرفة الرقم الصحيح الذي نرغب باختياره نقوم بتحديد الصلاحيات المطلوبة من الجدول التالي، ومن ثم جمع أعدادها: صلاحية القراءة تأخذ الرقم 4.صلاحية الكتابة تأخذ الرقم 2.صلاحية التنفيذ تأخذ الرقم 1.وهكذا يجب علينا جمع هذه الأرقام ثلاث مرات منفصلة (مرة لكل فئة) للحصول على الترميز المطلوب لملف ما، حيث يتم إعطاء الرقم 7 للفئة التي نريد إسناد صلاحيات القراءة والكتابة والتنفيذ لها (4+2+1) بينما تحصل الفئة التي نرغب بمنعها من كافة الصلاحيات على الرقم (0). لنعود مجددًا إلى مجلد acpi السابق كمثال، وباعتبار أن مالكه يجمع الصلاحيات الثلاث معًا فهو يأخذ الرقم 7، بينما تأخذ كل من المجموعة المالكة وفئة الآخرين الرقم (5)، ليكون الترميز الكامل للمجلد على الشكل 755. وكما في الترميز الأبجدي، يمكن للترميز العددي أن يضم بادئة تعبّر عن نوع الملف، وهذا يتبع لصلاحيات المالك، والمجموعة المالكة، وفئة الآخرين على الترتيب. استخدام الأمر chmodيعتبر الأمر chmod الطريقة الأكثر انتشارًا لتعديل صلاحيات ملف ما باستخدام الترميز العددي (الثماني)، لنأخذ مثالًا عمليًا على الفور: سوف ننشئ في مجلد المنزل ملفًا فارغًا باسم testfile لذلك: cd touch testfile ولنستعرض الآن الصلاحيات التي تعطى للملف بشكل افتراضي عند إنشاءه: ls -l testfile -rw-rw-r-- 1 demouser demouser 0 Jul 10 17:23 testfileوكما هو واضح فإن كلًا من مالك الملف والمجموعة المالكة له تملك أذونات القراءة والكتابة، بينما لا تملك فئة الآخرين سوى صلاحية القراءة. عند تحويل الترميز الأبجدي السابق إلى ترميز عددي، سيحصل كل من المالك والمجموعة المالكة على القيمة (6) (4 للقراءة و 2 للكتابة)، بينما تحصل فئة الآخرين على القيمة (4) فقط (للقراءة)، وهكذا يمكن تمثيل صلاحيات الملف testfile وفق الترميز العددي بالقيمة (664). لنفترض مثلًا أن الملف السابق يضم نصّ تنفيذي script، ونريد أن نضيف صلاحيات التنفيذ للمالك فقط، إضافةً لسحب صلاحيات التعديل عن المجموعة المالكة، بينما لا نعطى فئة الآخرين أيّة صلاحيات على الإطلاق. يمكن تمثيل الصلاحيات الجديدة بعد التعديل وفق الترميز الأبجدي كما يلي -rwxr-----، بينما تأخذ القيمة (740) في التمثيل العددي، لنستخدم الأمر chmod للتعديل على أذونات الملف: chmod 740 testfile ls -l testfile -rwxr----- 1 demouser demouser 0 Jul 10 17:23 testfile وهكذا نتأكد أن حسابنا صحيح، وقد أسند للملف صلاحياته الجديدة، وبذات الطريقة يمكن إعادة ضبط الأذونات على ما كانت عليه: chmod 664 testfile ls -l testfile -rw-rw-r-- 1 demouser demouser 0 Jul 10 17:23 testfileضبط الأذونات الافتراضية باستخدام Umaskتتحكّم الأداة umask بالأذونات المبدئية للملفات والمجلدات عند إنشائها بناء على صلاحيات الأساس "base"، حيث تعطى الصلاحية ذات القيمة (666) للملفات فور إنشائها، والتي تشمل أذونات القراءة والكتابة لفئات المستخدمين الثلاث (المالك، المجموعة المالكة، والآخرين)، ولا تشمل الأذونات الافتراضية صلاحية التنفيذ لأيّ من الملفات المنشأة، باعتبار أن معظمها لا يضم نصوصًا تنفيذية، كما أن إعطاء صلاحية التنفيذ بشكل افتراضي يفتح الباب أمام بعض المخاوف الأمنية. أما المجلدات فتعطى الصلاحية ذات القيمة (777) أي القراءة والكتابة والتنفيذ لجميع المستخدمين. يسمى الأسلوب الذي تعمل به الأداة umask بقناع الطرح subtractive mask، فطالما أن صلاحية التنفيذ لا يمكن أن تعطى بشكل افتراضي، فهذا يعني أن umask يعطي افتراضيًا أعلى الأذونات الممكنة، وهكذا فالتعديل الوحيد الممكن على قيمه الافتراضية هو بتقليل تلك الأذونات، وبعبارة أخرى إنشاء طبقة (أو قناع) تطرح بعض الأذونات المبدئية من صلاحيات الأساس. فعلى سبيل المثال، لو رغبنا بطرح صلاحية الكتابة من فئة الآخرين للمجلدات المنشأة (بحيث تبقى للمالك والمجموعة المالكة فقط)، فهذا يعني أن الأذونات الافتراضية يجب أن تصبح برقم (755)، ولإدخال التعديلات باستخدام الأداة umask نطرح الأذونات الأساسية من الأذونات المطلوبة لنحصل على قناع الطرح لحالتنا هذه: 777 - 775 ------ 002الناتج (002) هو القيمة التي سنمررها إلى umask لإدخال التعديلات المرغوبة، وفي الحقيقة يصادف أحيانًا أن تكون هذه هي القيمة الافتراضية لبعض الأنظمة كما مرّ معنا سابقًا عندما أنشأنا ملف جديد باستخدام الأمر touch، لنعيد المثال مرّة أخرى: touch test2 ls -l test2 -rw-rw-r-- 1 demouser demouser 0 Jul 10 18:30 test2 وإذا أردنا تأمين حماية أفضل لنظام تشغيلنا، فيمكن تعديل الأذونات المبدئية للملفات المنشأة بحيث لا تتيح لغير المالك أية صلاحيات على الإطلاق، عبر تمرير قناع الطرح (077) للأداة umask لتصبح صلاحيات الأساس الجديدة (600): umask 077 touch restricted ls -l restricted -rw------- 1 demouser demouser 0 Jul 10 18:33 restricted ولقلب العملية، أي لإعطاء كامل الصلاحيات لكافة فئات المستخدمين للملفات والمجلدات المنشأة فإننا نستخدم قناع الطرح (000): umask 000 touch openfile ls -l openfile -rw-rw-rw- 1 demouser demouser 0 Jul 10 18:36 openfile تُطبّق القيم الجديدة لصلاحيات الأساس عبر umask للجلسة الحاليّة فقط، وهذا يعني أنه عند إعادة التشغيل أو تسجيل الخروج، سيتم إعادة ضبط umask للقيم الافتراضية التي تُحدّدها توزيعتك، أما لجعل تغييراتك دائمة لكافة الجلسات القادمة فيجب تمرير قناع الطرح المطلوب إلى ملف bashrc. الخاص بمستخدمك: cd nano .bashrcتأكد أولًا فيما إذا كان هناك سطر يحدّد قيمة قناع الطرح umask، في هذه الحالة أدخل التعديل على القيمة المسندة له فقط، في غير ذلك أضف السطر التالي إلى نهاية الملف بالقيم التي تريد: umask 022 في مثالنا هذا مررنا كامل الصلاحيات لفئة المالك، بينما سحبنا صلاحيات الكتابة لكل من المجموعة المالكة وفئة الآخرين، بعد تحديد القناع الذي ترغب باختياره قم بحفظ الملف وإعادة تسجيل الدخول. إشعار تحذيريجب لفت الانتباه لنقطة مهمة تتعلق بتعديل الأذونات، حيث أن بعض ملفات النظام، وبعض الخدمات أو العمليات تتطلب صلاحيات معينة لتعمل بشكل صحيح، وإلا فستؤدي الصلاحيات غير الملائمة لأخطاء في التشغيل. إضافةً إلى أن توزيع الصلاحيات بشكل متساهل (مثل تمرير أذونات التنفيذ لفئة الآخرين بشكل تلقائي) قد تعرّضك لمشاكل أمنية. لهذه الأسباب (وغيرها) لا يُنصح بتعديل أذونات الملفات أو المجلدات خارج نطاق دليل المنزل الخاص بك، إلا إذا كنتَ على درايةً دقيقة بما تقوم به. أمرٌ آخر أودّ الإشارة إليه هنا، لأولئك الذين يقومون بضبط البرامج بشكل يدوي، وهي أهمية محاولة تمرير أقل صلاحيات ممكنة للبرنامج مع مراعاة ألّا يؤثر ذلك بالطبع على وظائفه. وفيما إذا كنتَ المستخدم الوحيد لجهازك (مدير خادوم مثلًا) فأنت تحتاج إلى صلاحيات مطلقة على الملفات، لكن إسناد أية صلاحيات لفئة الآخرين (كالكتابة أو حتى القراءة) لا داعي له سوى جلب المخاطر الأمنية، لا سيما في حال كانت كلمة المرور خاصتك مخزنة في ملف نصيّ غير مشفّر plain-text. وبالاستفادة من فئة (المجموعة المالكة) وإسناد الأذونات المناسبة لها، ومن ثم إضافة الأشخاص اللازمين من فريق العمل إليها، يمكن تحقيق أفضل منفعة ممكنة من إدارة الصلاحيات في لينكس، إضافةً إلى إلغاء صلاحيات "الآخرين" فيما لو لم يكن هناك حاجةٌ إليها، مما يحقق مستوىً عالٍ من الأمان. * الأذونات أو Permissions: هي مجموعة من القواعد تحدّد أولئك الذين يحق لهم أو لا يحق لهم امتلاك إمكانية القراءة، الكتابة، أو التعديل، على الملفات والمجلدات، وقد استخدمنا لها عدّة ترجمات في هذا الدليل؛ الأذونات، الصلاحيات، التصاريح. ترجمة -وبتصرّف- للمقال Linux Permissions Basics and How to Use Umask on a VPS.

هناك العديد من لغات قواعد البيانات SQL التي تعمل على أنظمة اللينكس واليونكس، ومن أشهر لغات قواعد البيانات العلائقية التي تعمل في بيئات الخوادم هما MySQL وMariaDB. ومع ذلك، مثل أغلب البرامج، هذه الأدوات يمكن أن تكون الاحتياجات الأمنية إذا تم تكوينها بشكل غير صحيح، هذا الشرح التعليمي سوف يرشدك لبعض الخطوات الأساسية التي يمكن اتخاذها لتأمين قاعدة البيانات الخاصة بك سواء MariaDB أو MySQL، والتأكد من أنها ليست بابًا مفتوحًا إلى VPS الخاص بك. من أجل البساطة والوضوح، سوف نستخدم MySQL على خادوم Ubuntu كمثال، ومع أن هذه التقنيات يمكن تطبيقها على توزيعات لينكس الأخرى، ويمكن استخدامها مع MariaDB كذلك. الإعداد الأوليMySQL يمنحك فرصة لاتخاذ الخطوة الأولى نحو تحقيق الأمن أثناء التثبيت، وسوف نطلب منكم وضع كلمة سر root (الجذر). $ sudo apt-get install mysql-server Configuring mysql-server-5.5 While not mandatory, it is highly recommended that you set a password for the MySQL administrative "root" user. If this field is left blank, the password will not be changed. New password for the MySQL "root" user:يمكنك دائما تعيين كلمة سر root في وقت لاحق، ولكن ليس هناك سبب لتخطي هذه الخطوة، لذلك يجب تأمين حساب المسؤول الخاص بك من البداية. بمجرد اكتمال التثبيت، يجب علينا تشغيل عدد قليل من النصوص المدرجة. أولاً، سوف نستخدم "mysql_install_db" وهو سكريبت نصي لإنشاء تصميم قواعد البيانات الخاصة بنا. $ sudo mysql_install_dbبعد ذلك، قم بتشغيل السكريبت الذي يسمى "mysql_secure_installation"، وسيرشدنا لبعض الإجراءات التي من شأنها إزالة بعض الافتراضات التي تشكل خطرا على استخدامها في بيئة الإنتاج. $ sudo mysql_secure_installationأولاً سوف يطلب منك إدخال كلمة السر الجذر وستقوم بإدخالها أثناء التثبيت، وبعد ذلك مباشرة ، سوف يطلب منك سلسلة من الأسئلة، بدءا من إذا كنت ترغب في تغيير كلمة سر الجذر. هذه هي فرصة أخرى لتغيير كلمة المرور الخاصة بك إلى أي شيء آمن إذا لم تكن قد فعلت ذلك بالفعل. يجب أن تكون الإجابة "Y" (نعم) لجميع الأسئلة المتبقية. سيؤدي ذلك إلى إزالة قدرة أي شخص لتسجيل الدخول إلى MySQL افتراضيا، وتعطيل تسجيل الدخول عن بعد على حساب المسؤول، وإزالة بعض قواعد بيانات الاختبار غير الآمنة، وتحديث قاعدة البيانات التي تعمل حاليا لاعتماد هذه التغيرات. اعتبارات أمنيةالقاعدة البسيطة لزيادة حماية MySQL (ومعظم الأنظمة الأخرى) هو إعطاء صلاحيات النفاذ فقط عند الضرورة. أحيانا لكي تكون بياناتك آمنة يجب أن توزان بين الراحة والأمان. في هذا الدليل، سوف نميل إلى الجانب الأمني، لذا فإن استخدامك الخاص لقاعدة البيانات يمكن أن يدفعك لإنتقاء أحد هذه الخيارات. زيادة الأمن من خلال ملف My.cnfملف الإعدادت الرئيسية في MySQL هو ملف يسمى "my.cnf" الموجود في "/etc/mysql/" هذا الامتداد على أوبونتو وامتداد "/etc/" على بعض الخواديم الأخرى. سوف نقوم بتغيير بعض الإعدادات في هذا الملف لتأمين MySQL الخاصة بنا. فتح الملف مع صلاحيات الجذر، تغيير مسار الامتداد حسب الحاجة إذا كنت تتبع هذا الشرح التعليمي على نظام مختلف: $ sudo nano /etc/mysql/my.cnfالإعداد الأولي التي يجب علينا أن نتحقق منه "وضع عنوان IP" ضمن قسم "[mysqld]". ويجب تعيين هذا الإعداد على جهاز الشبكة المحلي loopback ، وهو "127.0.0.1". $ bind-address = 127.0.0.1هذا يجعل من أن MySQL لا تقبل الاتصالات من أي مكان باستثناء الجهاز المحلي. إذا كنت بحاجة للوصول إلى قاعدة البيانات من جهاز آخر، خذ بالاعتبار الاتصال عن طريق SSH للقيام بالاستعلام وادارة قاعدة البيانات الخاصة بك محليا وإرسال النتائج من خلال قناة SSH. الفجوة التالية التي سوف نعدلها، هي وظيفة تتيح لك الوصول إلى نظام الملفات من داخل MySQL، يمكن أن يكون لها تداعيات أمنية خطيرة ويجب ايقافها إلا إذا كنت في حاجة شديدة لها. في نفس المقطع من الملف، سوف نقوم بإضافة التوجيه لتعطيل هذه القدرة على تحميل الملفات المحلية: local-infile=0إذا كان لدينا مساحة كافية ولا تعمل على قاعدة بيانات ضخمة، فإنه يمكن أن يكون مفيدا لتسجيل معلومات إضافية لمراقبة أي نشاط مثير للشبهة. تسجيل معلومات أكثر من اللازم يضعف الأداء، لذلك قم بوزن أي شيء تحتاجه بعناية. يمكنك وضع تسجيل الأحداث المتغيرة داخل القسم نفسه "[mysqld]" التي قمنا بالإضافة فيها: log=/var/log/mysql-logfileتأكد من أن سجل MySQL يعمل، سجل الأخطاء، وسجل MySQL ليس سهل القراءة: $ sudo ls -l /var/log/mysql* -rw-r----- 1 mysql adm 0 Jul 23 18:06 /var/log/mysql.err -rw-r----- 1 mysql adm 0 Jul 23 18:06 /var/log/mysql.log /var/log/mysql: total 28 -rw-rw---- 1 mysql adm 20694 Jul 23 19:17 error.logتأمين MySQL من الداخلهناك عدد من الخطوات التي يمكنك اتخاذها أثناء استخدام MySQL لتحسين الوضع الأمني. سوف نقوم بإدخال الأوامر في هذا القسم في بداخل واجهة MySQL ، لذلك نحن بحاجة إلى تسجيل الدخول. $ mysql -u root -pسيطلب منك إدخال كلمة سر الجذر التي قمت بإعدادها في وقت سابق. تأمين كلمات السر والمستخدمين المرتبطينأولاً، تأكد من وجود مستخدمين بدون كلمة مرور أو المضيف المرتبط في MySQL: SELECT User,Host,Password FROM mysql.user; +------------------+-----------+-------------------------------------------+ | user | host | password | +------------------+-----------+-------------------------------------------+ | root | localhost | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | demo-user | % | | | root | 127.0.0.1 | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | root | ::1 | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | debian-sys-maint | localhost | *ECE81E38F064E50419F3074004A8352B6A683390 | +------------------+-----------+-------------------------------------------+ 5 rows in set (0.00 sec)كما ترون في مثالنا هذا "المستخدم التجريبي " ليس لديه كلمة مرور، وهو ساري المفعول بغض النظر عن ما هو عليه في المضيف، ويعتبر هذا آمن جدا. يمكننا وضع كلمة سر للمستخدم مع هذا الأمر Change "كلمة المرور الجديدة" أدخل كلمة المرور التي ترغب بها. UPDATE mysql.user SET Password=PASSWORD('newPassWord') WHERE User=""demo-user";إذاً علينا التحقق من جدول المستخدم مرة أخرى، وسوف نرى أن المستخدم التجريبي لديه الآن كلمة سر: SELECT User,Host,Password FROM mysql.user;+------------------+-----------+-------------------------------------------+ | user | host | password | +------------------+-----------+-------------------------------------------+ | root | localhost | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | demo-user | % | *D8DECEC305209EEFEC43008E1D420E1AA06B19E0 | | root | 127.0.0.1 | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | root | ::1 | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | debian-sys-maint | localhost | *ECE81E38F064E50419F3074004A8352B6A683390 | +------------------+-----------+-------------------------------------------+ 5 rows in set (0.00 sec)إذا ما نظرت هذا الحقل"host"، سترى أن لا يزال لدينا "٪"، هي عبارة عن بطاقة بديلة وهذا يعني أي مضيف. وليس هذا ما نريده، دعونا نغيرها إلى " localhost". UPDATE mysql.user SET Host='localhost' WHERE User="demo-user";إذا تحققنا مرة أخرى، يمكننا أن نرى أن جدول المستخدم لديه الآن الحقول المناسبة. SELECT User,Host,Password FROM mysql.user;إذا كان لدينا جدول يحتوي على مستخدمين فارغين (لا يجب في هذه المرحلة أن يكونوا "mysql_secure_installation", سنغطي هذه الناحية بأي حال من الأحوال لاحقا)، وينبغي علينا إزالتهم. للقيام بذلك، يمكننا استخدام الأمور التالي لحذف المستخدمين الفارغين من جدول الوصول: DELETE FROM mysql.user WHERE User="";بعد أن يتم تعديل جدول المستخدم، نحن بحاجة إلى إدخال الأمر التالي لتنفيذ صلاحيات جديدة: FLUSH PRIVILEGES;إنشاء مستخدمين محددين لتطبيقات معينة طريقة تشغيل العمليات داخل لينكس تكون معزولة لكل مستخدم على حدى، وتستخدم قاعدة بيانات MySQL نفس طريقة العزل. كل تطبيق يستخدم MySQL يجب أن يمتلك مستخدم خاص به ولديه صلاحيات محدودة ويستطيع الوصول إلى قواعد البيانات التي يحتاج لتشغيلها فقط. عندما نقوم بإعداد تطبيق جديد لاستخدام MySQL، يجب أن ننشئ قواعد البيانات التي يحتاجها هذا التطبيق: create database testDB; Query OK, 1 row affected (0.00 sec)بعد ذلك، يجب علينا إنشاء مستخدم لإدارة قاعدة البيانات، ومنحه الصلاحيات التي يحتاجها فقط، وهذه تختلف من تطبيق لآخر، وبعض الاستخدامات تحتاج لصلاحيات مفتوحة أكثر من غيرها. لإنشاء مستخدم جديد، استخدم الأمر التالي: CREATE USER 'demo-user'@'localhost' IDENTIFIED BY 'password';يمكننا منح المستخدم الجديد صلاحيات على الجدول الجديد بالأمر التالي. انظر الشرح التعليمي حول كيفية إنشاء مستخدم ومنح صلاحيات جديدة في MySQL لمعرفة المزيد عن الصلاحيات المحددة: GRANT SELECT,UPDATE,DELETE ON testDB.* TO 'demo-user'@'localhost';وكمثال على ذلك، إذا كنا بحاجة إلى وقت لاحق لإلغاء الصلاحيات من الحساب، يمكن أن نستخدم الأمر التالي: REVOKE UPDATE ON testDB.* FROM 'demo-user'@'localhost';إذا كنا بحاجة إلى كافة الصلاحيات على قاعدة بيانات معينة، يمكننا تحديد ذلك بما يلي: GRANT ALL ON testDB.* TO 'demo-user'@'localhost';لإظهار الصلاحيات الحالية للمستخدم، علينا أولا أن ننفذ الصلاحيات حددناه باستخدام أمر "flush privileges"، ثم بعد ذلك يمكننا الاستعلام عن الصلاحيات التي بحوزة المستخدم. FLUSH PRIVILEGES; show grants for 'demo-user'@'localhost'; Grants for demo-user@localhost GRANT USAGE ON *.* TO 'demo-user'@'localhost' IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' GRANT SELECT, UPDATE, DELETE ON `testDB`.* TO 'demo-user'@'localhost' 2 rows in set (0.00 sec)دائما امسح الصلاحيات عندما تنتهي من إجراء التغييرات. تغيير المستخدم الجذرخطوة إضافية واحدة وهي، ربما تريد تغيير اسم الجذر(root login name )، فإذا كان الهاكر يحاول أن يقوم بتسجيل الدخول باسم الروت في MySQL ، فسوف يحتاج إلى تنفيذ خطوة إضافية هي العثور على اسم المستخدم. تستطيع تغيير اسم المستخدم روت باستخدام الأمر التالي: rename user 'root'@'localhost' to 'newAdminUser'@'localhost';يمكننا أن نرى التغيير باستخدام نفس الاستعلام الذي استخدمناه لقاعدة بيانات المستخدم: select user,host,password from mysql.user;مرة أخرى، يجب علينا مسح الصلاحيات التغيرات التي حدثت: FLUSH PRIVILEGES;تذكر أنه سوف تسجل دخول إلى MySQL مثل اسم مستخدم تم إنشاؤه حديثا عندما ترغب في أداء المهام الإدارية: mysql -u newAdminUser -pبأي حال من الأحوال هذه قائمة شاملة من الاجراءات الأمنية لقواعد البيانات MySQL, MariaDB، وقد أصبح لديك مقدمة جيدة لأنواع القرارات التي ستتخذها عندما تريد تأمين قواعد البيانات الخاصة بك. يمكن الاطلاع على مزيد من المعلومات حول الإعدادت والأمن في قواعد بيانات المواقع MySQL وMariaDB إضافة الى صفحات المختصين، ويمكن للتطبيقات التي اخترت استخدامها أن تقدم المشورة الأمنية. ترجمة -وبتصرّف- للمقال: How To Secure MySQL and MariaDB Databases in a Linux VPS.