سؤال ما هي أفضل طريقة للتعامل مع أذونات مستخدم الويب الخاص بـ Apache 2 في www / var / www؟


وقد أي شخص حصلت على حل لطيف للتعامل مع الملفات في /var/www؟ نحن نقوم بتشغيل Host Virtual Based Name ويكون مستخدم Apache 2 شبكة الاتصالات العالمية بيانات.

لدينا اثنين من المستخدمين العاديين والجذر. لذلك عند العبث مع الملفات في /var/www، بدلا من الاضطرار إلى ...

chown -R www-data:www-data

... طوال الوقت ، ما هي طريقة جيدة للتعامل مع هذا؟

سؤال تكميلي: كيف المتشددين هل تذهب إذن على الأذونات؟

هذا واحد كان دائما مشكلة في بيئات التعاون التعاوني.


211
2018-05-11 05:13


الأصل


انظر أيضا: ما هي أفضل أذونات Linux لاستخدامها لموقع الويب الخاص بي؟ - Zoredache


الأجوبة:


محاولة التوسع على @ Zoredache إجابة، وأنا أعطي هذا يذهب بنفسي:

  • أنشئ مجموعة جديدة (www-pub) وأضف المستخدمين إلى تلك المجموعة

    groupadd www-pub

    usermod -a -G www-pub usera  يجب استخدام ## a لإلحاق بالمجموعات الموجودة

    usermod -a -G www-pub userb

    groups usera  ## مجموعات العرض للمستخدم

  • غيّر ملكية كل شيء تحت / var / www إلى الجذر: www-pub

    chown -R root:www-pub /var/www  ## -R للتكرار

  • تغيير أذونات جميع المجلدات إلى 2775

    chmod 2775 /var/www  ## 2 = تعيين معرف المجموعة ، 7 = rwx للمالك (الجذر) ، 7 = rwx للمجموعة (www-pub) ، 5 = rx للعالم (بما في ذلك مستخدم apache www-data)

    تعيين معرف المجموعة (SETGID) تؤدي bit (2) إلى نسخ المجموعة (www-pub) إلى جميع الملفات / المجلدات الجديدة التي تم إنشاؤها في هذا المجلد. خيارات أخرى هي SETUID (4) لنسخ معرف المستخدم ، و STICKY (1) الذي أعتقد أنه يسمح فقط للمالك حذف الملفات.

    هناك -R خيار تكراري ، ولكن هذا لن يميز بين الملفات والمجلدات ، لذلك عليك استخدام البحث، مثل ذلك:

    find /var/www -type d -exec chmod 2775 {} +

  • قم بتغيير كافة الملفات إلى 0664

    find /var/www -type f -exec chmod 0664 {} +

  • تغيير umask للمستخدمين الخاص بك إلى 0002

    يتحكم umask في أذونات إنشاء الملف الافتراضية ، 0002 يعني أن الملفات تحتوي على 664 والأدلة 775. إعداد هذا (عن طريق تحرير umask خط في الجزء السفلي من /etc/profile في حالتي) يعني أن الملفات التي أنشأها مستخدم واحد ستكون قابلة للكتابة من قبل مستخدمين آخرين في مجموعة www دون الحاجة إلى ذلك chmod معهم.

اختبر كل هذا عن طريق إنشاء ملف ودليل والتحقق من المالك والمجموعة والأذونات باستخدام ls -l.

ملاحظة: ستحتاج إلى تسجيل الخروج / من أجل تفعيل التغييرات في مجموعاتك!


201
2017-09-15 05:11



Tom رائع لترى أنك توصي باستخدام findالأمر لهذا. إن أحد أطراف الأداء الصغيرة التي سأقدمها إذا كان لديك الكثير من الملفات / الأدلة وكنت تستخدم بحث جنو هو الاستخدام + بدلا من \; بحيث الأمر سوف تعمل على ملفات متعددة لان "من الأسرع تشغيل أمر على أكبر عدد ممكن من الملفات في كل مرة ، بدلاً من مرة واحدة لكل ملف. يؤدي ذلك إلى توفير الوقت المستغرق لبدء الأمر في كل مرة." أيضًا ، من الأسهل الكتابة حيث لا تحتاج إلى شرطة مائلة للخلف. - aculich
تم التحديث مع اقتراح aculich @ لاستخدام + not \؛ - Tom
SunnyJ. جرب هذا (بدون الاقتباسات الخارجية): "find / var / www -type f -exec chmod 0664" {} "\ +" جرب ذلك. هناك مسافة بين '{}' و \ +. - Buttle Butkus
@ توم - طريقة لتفكيكها ، وذلك بفضل. مجرد ملاحظة - أعتقد أن "SETUID (4) لنسخ معرف المستخدم" كما هو مضمن في إجابتك خاطئ - يتم تجاهل SETUID عند تطبيقه على الدلائل في Linux / Unix - المرجع - Yarin
حسنا ، لذلك من قبل usera و userb هل تعني www-data و ftpuser ؟ لقد وجدت هذا مربكًا جدًا مع أي ذكر لـ www-data، والذي كان في السؤال الأصلي. أيضا ، ما هي الفائدة / الفائدة من تعيين المالك ل root؟ يجب أن نضعها ftpuser؟ - gskema


لست متأكدًا تمامًا من كيفية تكوين الأذونات ، ولكن قد يمنحك ذلك نقطة بداية. ربما هناك طرق أفضل. أفترض أنك تريد أن يتمكن كل من المستخدمين من تغيير أي شيء ضمن / var / www /

  • أنشئ مجموعة جديدة (www-pub) وأضف المستخدمين إلى تلك المجموعة.
  • غيّر ملكية كل شيء تحت / var / www إلى الجذر: www-pub.
  • تغيير أذونات جميع المجلدات إلى 2775
  • قم بتغيير كافة الملفات إلى 0664.
  • تغيير umask للمستخدمين الخاص بك إلى 0002

يعني هذا أن أي ملف جديد تم إنشاؤه بواسطة أي من المستخدمين يجب أن يكون اسم المستخدم: www-pub 0664 وأي دليل يتم إنشاؤه سيكون اسم المستخدم: www-pub 2775. ستحصل Apache على حق الوصول إلى كل شيء عبر مكون "المستخدمين الآخرين". سيؤدي SETGID بت على الدلائل إلى فرض كافة الملفات التي يتم إنشاؤها المملوكة للمجموعة التي تملك المجلد. هناك حاجة إلى ضبط umask للتأكد من تعيين بت الكتابة بحيث يتمكن أي شخص في المجموعة من تحرير الملفات.

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


59
2018-05-11 05:49



إضافة محتملة - تعيين ذاكرة التخزين المؤقت / تحميل التطبيق الذي تحتاج إلى كتابته من قبل خادم الويب إلى www-data: www-data و 775. - gacrux
هل ستعمل أيضًا لإضافة المستخدمين إلى مجموعة أباتشي بدلاً من الاعتماد على أذونات "أخرى"؟ إذا كان كل ما تقوم به هو تحميل الملفات وتحتاج تلك الملفات إلى أن تكون قابلة للقراءة بواسطة apache ، فإن المجموعة الثالثة تبدو مفيدة فقط إذا كنت تحتاج إلى تعديل هذه الملفات. - Simurr
أي فرصة يمكنك توسيع هذا قليلاZoredache؟ أنا grok الاستخدام الأساسي من بت rwx ، chmod ، chown ، adduser ، usermod ، ولكن كنت قد فقدت لي مع الرقم الأول إضافي على أذونات ثماني ، umasks وكل ذلك. سيكون موضع تقدير كبير بعض أوامر عينة توضيح المخططات الخاص بك. - Tom
بهذه الطريقة يمكن لكل مستخدم الوصول إلى كل ملفات المستخدم الأخرى! هذا يعني أن userA يمكن قراءة config.php من userB ... سرقة بيانات الاعتماد الخاصة به على mysql ، على سبيل المثال - drAlberT
باستخدام ACL يمكنك التعامل مع كل من الأمن والتعاون :) - drAlberT


أعتقد أنك قد تجد POSIX ACL (قوائم التحكم في الوصول) مفيدة. أنها تسمح بنموذج إذن أدق مقارنة مع المستخدم: المجموعة: نموذج آخر. لقد وجدتها أسهل في رأسي مباشرة حيث يمكنني أن أكون أكثر وضوحًا ويمكن أيضًا ضبط السلوك "الافتراضي" لفرع من نظام الملفات.

على سبيل المثال ، يمكنك تحديد أذونات كل مستخدم بشكل صريح:

setfacl -Rm d:u:userA:rwX,u:userA:rwX /var/www
setfacl -Rm d:u:userB:rwX,u:userB:rwX /var/www

أو يمكنك القيام بذلك بناءً على بعض المجموعات المشتركة:

setfacl -Rm d:g:groupA:rwX,u:groupA:rwX /var/www

وربما ترغب في الحفاظ على مستخدم أباتشي الخاص بك للقراءة فقط

setfacl -Rm d:u:www-data:rX,u:www-data:rX /var/www

صفحات رجل:

الدورة التعليمية


39
2018-05-11 16:26



هذا الطريقة ! +1 - drAlberT
ACL للفوز +1 ... لمزيد من المعلومات serverfault.com/a/360120/41823 - Yarin
أتساءل عما إذا كان هناك أي جانب سلبي لأداء ACL مقابل الأذونات الأساسية. - Buttle Butkus
للأسف ، كثيرًا ما تكون ACL مفقودة في عمليات التثبيت / التوزيعات القياسية. إنه ألم لتجميع نواة على كل خوادم أديرها ، أو أسوأ من ذلك ، تغيير نظام الملفات في بعض الأحيان. بالإضافة إلى ذلك ، يجب أن تكون حذراً للغاية عند نسخ الملفات احتياطياً ، خاصةً إذا كنت تقوم بتحويل الخوادم. ACL رائع ولكن دعمه الحالي منخفض للغاية لدرجة أنني أوصي به ضد أي شخص لا يملك السيطرة الكاملة على كل شيء على الخادم والمناطق المحيطة به. ولكن إجراء 1+ للإشارة إلى قائمة التحكم في الوصول (ACL) حيث يكون الأمر معقولًا حقًا! - Ninj
إجابة جيدة +1؛ ملاحظة حول تغيير أذونات قراءة / كتابة عملية apache (www-data على سبيل المثال) للقراءة فقط للموقع بأكمله (عبر setfacl أو chmod - أو كليهما) -> من الواضح أن هذا سيؤدي إلى حظر جميع عمليات الكتابة (الإضافات / الوحدة النمطية للتحميل / التحديث من جانب المتصفح على معظم CMS على سبيل المثال). وأعتقد أن العديد من الشعبية منها أيضا اختبار فقط لكتابة الوصول على مستوى بيرم المستخدم وليس على مستوى المجموعة. لا يزال بإمكانك التحديث ، ولكن يجب تطبيق التحديثات يدويًا وأي أذونات مخصصة لمجلدات الكتابة (سجلات / temp / uploads / etc). للقراءة فقط هي أمان كبير إذا كان موقعك يعمل معها .. وعلى العموم لا يفعل ذلك. - bshea


كان هذا السؤال سأل مرة أخرى، و كما ناقش في الفوقية ، توفر أفضل الممارسات الحالية أساليب أفضل مما كان متاحًا في عام 2009 ، عندما طُلب ذلك. هذه الاجابة تحاول تقديم بعض الحلول الحالية التعامل مع بيئات تطوير الويب التعاونية بشكل آمن.


للحصول على خادم ويب آمن وتعاونية ، هناك أكثر من مجرد أذونات الملفات:

  • لديك مستخدم منفصل لكل موقع بمعنى ، عدم عرض جميع المواقع باستخدام www-data. هذا أمر مهم ، حيث أن Apache في الوقت الحاضر نادراً ما يخدم فقط ثابتة ملفات المحتوى ، ولكن قيد التشغيل ديناميكي مواقع الويب. هذه الإجابة تركز على PHP كما هو الاكثر انتشارا لغة خادم الموقع ، لكن المبادئ نفسها تنطبق على الآخرين أيضًا.

    إذا كان لديك مشكلة أمان على موقع واحد ، يمكن أن ينتشر إلى كل موقع يعمل كمستخدم نفس. يمكن للمهاجم مشاهدة كل ما يراه المستخدم ، بما في ذلك معلومات تسجيل الدخول إلى قاعدة البيانات وتعديل كل موقع يمتلك المستخدم أذونات الكتابة إليه.

  • استعمال SSH بروتوكول نقل الملفات (SFTP). أثناء استخدام FTP يجب أن يتم التخلي عنه للأمان (حيث أنه يرسل كل من كلمات المرور والمحتوى في نص عادي) ، فهو بديل آمن SFTP له أيضًا ميزة تمثل حلاً مثاليًا لتطوير الويب التعاوني.

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

    يمكن لكل مطور توليد keypair والحفاظ على سرية المفتاح الخاص. ثم ، يتم إضافة المفتاح العام إلى ~/.ssh/authorized_keys ملف لكل حساب مستخدم موقع ويب يعمل المطور على. هذا له العديد من المزايا لإدارة كلمات المرور وتسجيلات الدخول:

    • يمكن لكل مطور الوصول إلى أي عدد من مواقع الويب بدون عبء لتذكر أو تخزين جميع كلمات المرور المرتبطة بترتيب المستخدم لكل موقع.

    • لا حاجة لتغيير ومشاركة كلمات المرور في كل مرة يغادر فيها شخص ما الشركة.

    • يمكنك استخدام كلمات مرور قوية جدًا أو تعطيل كلمة المرور المستندة إلى كلمة المرور تمامًا.

  • استخدم PHP-FPM. إنها الطريقة الحالية لتشغيل PHP كمستخدم. خلق جديد حوض السباحة لكل مستخدم ، أي مسبح واحد لكل موقع. هذا هو الأفضل للأمان والأداء ، حيث يمكنك أيضًا تحديد مقدار الموارد التي يمكن أن يستهلكها موقع واحد.

    انظر على سبيل المثال وNeverEndingSecurity قم بتشغيل php-fpm مع مستخدم و uid منفصلين ومجموعات على linux. هناك دروس مثل HowtoForge استخدام PHP-FPM مع Apache على Ubuntu 16.04 التي لا تستخدم PHP-FPM لزيادة الأمان من خلال فصل المستخدم ، وتوجيه لاستخدام مقبس FPM واحد عبر الخادم.


7
2018-05-10 10:03