सवाल WWW फ़ोल्डर के लिए लिनक्स अनुमतियों को कैसे सेट करें?


अद्यतन सारांश

/ Var / www निर्देशिका का स्वामित्व है root:root जिसका मतलब है कि कोई भी इसका उपयोग नहीं कर सकता है और यह पूरी तरह से बेकार है। चूंकि हम सभी एक वेब सर्वर चाहते हैं जो वास्तव में काम करता है (और कोई भी "रूट" के रूप में लॉग इन नहीं होना चाहिए), तो हमें इसे ठीक करने की आवश्यकता है।

केवल दो इकाइयों को पहुंच की आवश्यकता है।

  1. PHP / पर्ल / रूबी / पायथन सभी को फ़ोल्डरों और फ़ाइलों तक पहुंच की आवश्यकता है क्योंकि उनमें से कई (यानी। /uploads/)। ये स्क्रिप्टिंग भाषाओं को nginx या apache (या PHP के लिए FastCGI जैसी कुछ अन्य चीज़ों के तहत) चलाना चाहिए।

  2. डेवलपर्स

वे कैसे पहुंच प्राप्त करते हैं? मुझे पता है कि कोई कहीं पहले यह किया है। हालांकि वहां कई अरब वेबसाइटें हैं, आपको लगता है कि इस विषय पर और जानकारी होगी।


मुझे पता है कि 777 मालिक / समूह / अन्य के लिए पूर्ण पढ़ने / लिखने / निष्पादित अनुमति है। तो ऐसा प्रतीत नहीं होता है जरूरत है सही है क्योंकि यह यादृच्छिक उपयोगकर्ताओं को पूर्ण अनुमति देता है।

किस अनुमति का उपयोग करने की आवश्यकता है /var/www ताकि:

  1. स्रोत नियंत्रण जैसे गिट या एसवीएन
  2. "वेबसाइट" जैसे समूह में उपयोगकर्ता (या यहां तक ​​कि "www-data" में जोड़ा गया)
  3. Apache या Lighthttpd जैसे सर्वर
  4. और PHP / पर्ल / रूबी

क्या सभी फाइलें (और निर्देशिका) को पढ़ सकते हैं, बना सकते हैं और चला सकते हैं?

यदि मैं सही हूं, रूबी और PHP स्क्रिप्ट सीधे "निष्पादित" नहीं हैं - लेकिन एक दुभाषिया को पास कर दिया गया है। इसलिए फाइलों पर निष्पादन अनुमति की आवश्यकता नहीं है /var/www...? इसलिए, ऐसा लगता है कि सही अनुमति होगी chmod -R 1660 जो करेगा

  1. इन चार इकाइयों द्वारा साझा की जाने वाली सभी फाइलें
  2. सारे दस्तावेज गलती से निष्पादन योग्य नहीं
  3. निर्देशिका से पूरी तरह से सभी को अवरुद्ध करें
  4. सभी भविष्य की फ़ाइलों के लिए अनुमति चिपकाने के लिए "चिपचिपा" सेट करें

क्या ये सही है?

अद्यतन 1: मुझे अभी एहसास हुआ कि फ़ाइलों और निर्देशिकाओं को अलग-अलग अनुमतियों की आवश्यकता हो सकती है - मैं उपरोक्त फ़ाइलों के बारे में बात कर रहा था इसलिए मुझे यकीन नहीं है कि निर्देशिका अनुमतियों की क्या आवश्यकता होगी।

अद्यतन 2: की फ़ोल्डर संरचना /var/www उपरोक्त चार इकाइयों में से एक के रूप में भारी रूप से परिवर्तन होते हैं (फ़ोल्डर्स और उप फ़ोल्डर्स) कई स्तरों को गहराई से जोड़ते हैं (और कभी-कभी हटाते हैं)। वे उन फ़ाइलों को भी बनाते और हटाते हैं जिन्हें अन्य 3 इकाइयों को पढ़ने / लिखने की आवश्यकता हो सकती है। इसलिए, अनुमतियों को दोनों फाइलों और निर्देशिकाओं के लिए उपरोक्त चार चीजें करने की आवश्यकता है। चूंकि उनमें से कोई भी निष्पादन अनुमति की आवश्यकता नहीं है (ऊपर रूबी / PHP के बारे में प्रश्न देखें) मैं इसे मानूंगा rw-rw-r-- अनुमति की आवश्यकता होगी और पूरी तरह से सुरक्षित है क्योंकि इन चार इकाइयों द्वारा संचालित किया जाता है भरोसेमंद कर्मियों (देखें # 2) और सिस्टम के सभी अन्य उपयोगकर्ताओं को केवल पढ़ने के लिए उपयोग किया है।

अद्यतन 3: यह व्यक्तिगत विकास मशीनों और निजी कंपनी सर्वरों के लिए है। साझा होस्ट की तरह कोई यादृच्छिक "वेब ग्राहक" नहीं।

अद्यतन 4:  यह लेख स्लाइसहोस्ट द्वारा आपके www फ़ोल्डर के लिए अनुमतियों को सेट करने के लिए क्या आवश्यक है, यह समझाने में सबसे अच्छा प्रतीत होता है। हालांकि, मुझे यकीन नहीं है कि PHP या svn / git के साथ उपयोगकर्ता या समूह अपाचे / nginx क्या चल रहा है और उन्हें कैसे बदला जाए।

अद्यतन 5: मेरे पास (मुझे लगता है) अंत में यह सब काम करने के लिए एक रास्ता मिला (नीचे जवाब)। हालांकि, मुझे नहीं पता कि यह करने के लिए यह सही और सुरक्षित तरीका है या नहीं। इसलिए मैंने एक बक्षीस शुरू कर दिया है। जिस व्यक्ति के पास www निर्देशिका जीतने और प्रबंधित करने का सबसे अच्छा तरीका है।


61
2018-03-22 01:21


मूल




जवाब:


अधिक शोध के बाद यह उत्तर देने के लिए एक और (संभवतः बेहतर तरीका) जैसा लगता है जैसे www फ़ोल्डर को सेटअप करना होगा।

  1. sudo usermod -a -G developer user1 (प्रत्येक उपयोगकर्ता को डेवलपर समूह में जोड़ें)
  2. sudo chgrp -R developer /var/www/site.com/ ताकि डेवलपर वहां काम कर सकें
  3. sudo chmod -R 2774 /var/www/site.com/ ताकि केवल डेवलपर्स फाइलें बना / संपादित कर सकें (अन्य / दुनिया पढ़ सकते हैं)
  4. sudo chgrp -R www-data /var/www/site.com/uploads ताकि www-data (apache / nginx) अपलोड बना सके।

जबसे git जो भी उपयोगकर्ता इसे कॉल कर रहा है, तब तक चलता है, तब तक जब तक उपयोगकर्ता "डेवलपर" समूह में होता है, तब तक वे फ़ोल्डर्स बनाने, PHP फ़ाइलों को संपादित करने और गिट रिपोजिटरी प्रबंधित करने में सक्षम होना चाहिए।

नोट: चरण (3) में: 2774 में '2' का अर्थ निर्देशिका के लिए 'समूह आईडी सेट' करना है। यह मूल निर्देशिका की समूह आईडी (उपयोगकर्ता के प्राथमिक समूह की बजाय) के उत्तराधिकारी के लिए बनाई गई नई फ़ाइलों और उप निर्देशिकाओं का कारण बनता है संदर्भ: http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories 


47
2018-03-25 21:27



मुझे उचित लगता है। - wazoox
अच्छा। शायद अगर मैं इसे दो और लोगों के साथ पुष्टि कर सकता हूं तो मैं इस दृष्टिकोण का उपयोग करूँगा। ऐसा लगता है कि मैं लोगों से बाहर निकलने में सक्षम हूं। - Xeoncross
आप निर्दिष्ट नहीं कर रहे हैं कि फाइलों का मालिक कौन होगा। क्या आप इसे जड़ के रूप में छोड़ देंगे? फिर केवल sudoers आपके अपलोड फ़ोल्डर को संपादित कर सकते हैं (शायद आप जो चाहते हैं वह नहीं)। - Nic
हां, रूट मालिक बने रहेगा। हालांकि, चूंकि समूह के मालिक अब "डेवलपर" हैं (और इसमें wrx अनुमति है) तो सभी देव (और apache / nginx) भी पढ़ सकते हैं। सुडो के लिए कोई ज़रूरत नहीं है। - Xeoncross
उमास्क के लिए देखने के लिए एक और चीज है। कई प्रणालियों में 022 का डिफ़ॉल्ट umask होता है जो नई फ़ाइलों पर समूह और जनता दोनों के लिए लेखन अनुमतियां हटा देगा। मुझे संदेह है कि आप 002 (जनता के लिए कोई लिखना नहीं चाहते) या 007 (जनता के लिए कोई पहुंच नहीं)। आप किसी भी प्रक्रिया के लिए अपाचे की कॉन्फ़िगरेशन और / या स्टार्टअप स्क्रिप्ट में उमास्क सेट कर सकते हैं जिसके लिए निर्देशिका तक पहुंच की आवश्यकता है। इसे / etc / profile या / etc / bashrc में जोड़ने के लिए मत भूलना ताकि यह आपके डेवलपर्स के लिए डिफ़ॉल्ट रूप से सेट हो - Mark Porter


मुझे यकीन नहीं है कि यह "सही" है, लेकिन यहां मैं अपने सर्वर पर क्या करता हूं:

  • / var / www में प्रत्येक वेबसाइट के लिए एक फ़ोल्डर होता है।
  • प्रत्येक वेबसाइट में एक निर्दिष्ट मालिक होता है, जिसे वेबसाइट की निर्देशिका में सभी फ़ाइलों और फ़ोल्डरों के मालिक के रूप में सेट किया जाता है।
  • वेबसाइट बनाए रखने वाले सभी उपयोगकर्ता वेबसाइट के लिए समूह में डाल दिए जाते हैं।
  • यह समूह निर्देशिका में सभी फ़ाइलों और फ़ोल्डरों के समूह के मालिक के रूप में सेट है।
  • वेबसर्वर (यानी PHP) द्वारा लिखी जाने वाली किसी भी फाइल या फ़ोल्डर्स का स्वामी www-data में बदल जाता है, जो उपयोगकर्ता अपाचे चलाता है।

ध्यान रखें कि निर्देशिकाओं पर निष्पादन बिट सक्षम होना चाहिए ताकि आप सामग्री सूचीबद्ध कर सकें।


8
2018-03-22 02:52



गिट / एसवीएन या PHP कैसे नए फ़ोल्डर्स बनाते हैं? - Xeoncross
PHP वेब उपयोगकर्ता के समान उपयोगकर्ता संदर्भ में चलता है, इसलिए यह वेबसर्वर के स्वामित्व वाली किसी भी निर्देशिका में फ़ाइलें और फ़ोल्डर्स बना सकता है। आम तौर पर इस तरह के कुछ फ़ोल्डर्स होते हैं (/ अपलोड / उदाहरण के लिए)। मुझे गिट / एसवीएन के बारे में निश्चित नहीं है - क्या आप उन्हें उस समूह खाते में जोड़ सकते हैं जो वेबसाइट को नियंत्रित करता है? - Nic
स्पष्ट रूप से गिट चलाता है क्योंकि उपयोगकर्ता इसे चला रहा है - बस किसी भी अन्य उपकरण की तरह। - Xeoncross
फिर गिट उपयोगकर्ता को अपाचे समूह में जोड़ें और फ़ोल्डर समूह लिखने की अनुमति दें। - David Rickman
मैंने अभी कहा है, गिट में उपयोगकर्ता नहीं है - यह वर्तमान उपयोगकर्ता के रूप में इसका उपयोग करता है। - Xeoncross


अधिक शोध करने के बाद ऐसा लगता है कि गिट / svn उपकरण कोई समस्या नहीं है क्योंकि वे जो भी उपयोगकर्ता उनका उपयोग कर रहे हैं, चलते हैं। (हालांकि, गिट / एसवीएन डिमन्स एक अलग मामला हैं!) गिट के साथ बनाए गए / क्लोन किए गए सब कुछ में मेरी अनुमतियां थीं और गिट उपकरण सूचीबद्ध था /usr/bin जो इस थीसिस फिट बैठता है।

गिट अनुमतियों का हल हो गया।

उपयोगकर्ता अनुमतियों को उन सभी उपयोगकर्ताओं को जोड़कर हल करने योग्य प्रतीत होता है जिन्हें www निर्देशिका तक पहुंच की आवश्यकता होती है www-data समूह जो apache (और nginx) के रूप में चलाते हैं।

तो ऐसा लगता है एक जवाब इस सवाल के लिए इस तरह जाता है:

डिफ़ॉल्ट रूप से /var/www के स्वामित्व में है root:root तथा कोई नहीं वहां फाइलें जोड़ या बदल सकते हैं।

1) समूह के मालिक बदलें

सबसे पहले हमें "रूट" समूह के बजाय "www-data" के स्वामित्व वाले www निर्देशिका समूह को बदलने की आवश्यकता है

sudo chgrp -R www-data /var/www

2) उपयोगकर्ताओं को www-data में जोड़ें

फिर हमें वर्तमान उपयोगकर्ता (और कोई और) www-data समूह में जोड़ना होगा

sudo usermod -a -G www-data demousername

3) CHMOD www निर्देशिका

अनुमतियों को बदलें ताकि केवल स्वामी (रूट) और समूह "www-data" के सभी उपयोगकर्ता rwx (पढ़ / लिख / निष्पादित) फ़ाइलों और निर्देशिकाओं (कोई भी इसे एक्सेस करने में सक्षम नहीं होना चाहिए)।

sudo chmod -R 2770 /var/www

अब किसी भी उपयोगकर्ता द्वारा बनाई गई सभी फाइलें और निर्देशिकाएं (यानी "www-data" समूह में) अपाचे द्वारा पठनीय / लिखने योग्य और इसलिए php।

क्या ये सही है? PHP / रूबी बनाने वाली फ़ाइलों के बारे में क्या - www-data उपयोगकर्ता उन्हें एक्सेस कर सकते हैं?


6
2018-03-24 03:15



मुझे PHP द्वारा लिखने वाली सभी वेब फ़ाइलों को रखने का विचार पसंद नहीं है, यदि स्क्रिप्ट भेद्यता है तो यह आपके संभावित एक्सपोजर को बढ़ाता है। - Nic
ठीक है, ठीक है मुझे पता है कि मैं बहुत सारे बनाने के लिए PHP का उपयोग करता हूं पाठ, टैर, लॉग, और छवि फाइलें (प्लस फ़ोल्डर्स) तो मैं बस यह मान रहा था कि सब कुछ लिखने योग्य होना चाहिए। हालांकि, शायद आपका अधिकार और PHP केवल सक्षम होना चाहिए फाइलें बदलती हैं I जो हानिरहित होगा क्योंकि 99% सभी PHP ऐप्स कभी स्क्रिप्ट फाइल नहीं बनाते हैं। दूसरी पसंद केवल कुछ निर्देशिका PHP लिखने की पहुंच (/ अपलोड /) की अनुमति देती है जो तब से नहीं बनाती है क्योंकि तब PHP को अभी भी कुछ खराब बनाने के लिए उपयोग किया जा सकता है। कोई विचार? - Xeoncross
स्क्रिप्ट और डेटा को अलग रखने की कोशिश करें। यहां तक ​​कि यदि कोई हमलावर कुछ अपलोड / अपलोड करने का प्रबंधन करता है, तो यह निष्पादन योग्य नहीं होना चाहिए। परतों में सुरक्षा कुंजी है। - Nic


चिपचिपापन विरासत अनुमति नहीं है। किसी निर्देशिका पर चिपचिपापन का अर्थ है कि किसी फ़ाइल या मालिक के मालिक का स्वामी, अन्यथा कहने की अनुमति के बावजूद निर्देशिका में उस फ़ाइल का नाम बदल या हटा सकता है। इस प्रकार 1777 / tmp / पर।

शास्त्रीय यूनिक्स में, फ़ाइल-सिस्टम के आधार पर कोई अनुमति विरासत नहीं है, केवल वर्तमान प्रक्रिया 'उमास्क पर। निर्देशिका पर सेटजीड के साथ * बीएसडी, या लिनक्स पर, नव निर्मित फाइलों का समूह फ़ील्ड मूल निर्देशिका के समान ही सेट किया जाएगा। कुछ और के लिए, आपको निर्देशिकाओं पर 'डिफ़ॉल्ट' एसीएल के साथ एसीएल में देखना होगा, जो आपको विरासत अनुमतियां देता है।

आपको परिभाषित करके शुरू करना चाहिए:  * उपयोगकर्ताओं के पास सिस्टम तक पहुंच है  * आपका खतरा मॉडल क्या है

उदाहरण के लिए, यदि आप कई ग्राहकों के साथ वेब होस्टिंग कर रहे हैं और आप नहीं चाहते हैं कि वे एक-दूसरे की फाइलें देख रहे हों, तो आप उन सभी उपयोगकर्ताओं के लिए एक सामान्य समूह "वेबकस्ट्स" और 0705 के डायरेक्टरी मोड का उपयोग कर सकते हैं। फिर फाइलें वेबसर्वर प्रक्रिया (नहीं "वेबकस्ट्स" में) अन्य परमिट देखेंगे और अनुमति दी जाएगी; ग्राहक एक-दूसरे की फाइल नहीं देख सकते हैं और उपयोगकर्ता अपनी फाइलों के साथ गड़बड़ कर सकते हैं। हालांकि, इसका मतलब यह है कि जिस क्षण आप सीजीआई या PHP को अनुमति देते हैं है यह सुनिश्चित करने के लिए कि प्रक्रियाएं विशिष्ट उपयोगकर्ता के रूप में चलती हैं (वैसे भी अच्छा अभ्यास, जवाब-योग्यता के लिए एकाधिक-उपयोगकर्ता-ऑन-वन-होस्ट के लिए)। अन्यथा, ग्राहक एक सीजीआई ऐसा करके एक-दूसरे की फाइलों के साथ गड़बड़ कर सकते हैं।

हालांकि, यदि वेबसाइट के लिए रन-टाइम उपयोगकर्ता वेबसाइट के मालिक के समान है, तो आपको स्क्रिप्ट में सुरक्षा छेद के मामले में दुर्व्यवहारियों से सामग्री की रक्षा करने में सक्षम नहीं होने के साथ समस्याएं हैं। जहां समर्पित मेजबान जीतते हैं, ताकि आपके पास स्टैटिक सामग्री स्वामी से अलग रन-टाइम उपयोगकर्ता हो और अन्य उपयोगकर्ताओं के साथ बातचीत के बारे में चिंता न करें।


5
2018-03-22 03:37



अच्छा उत्तर। मैकोज़ एक्स पर, सिस्टम व्यवहार करता है जैसे एसजीआईडी ​​बिट स्वचालित रूप से निर्देशिकाओं पर है। चिपचिपा बिट आमतौर पर इसका मतलब है कि अगर आप इसे लिख सकते हैं तो आप केवल फाइल को हटा सकते हैं। यही है, कोई भी सार्वजनिक रूप से लिखने योग्य फ़ाइल को / tmp में हटा सकता है। मैकोज़ एक्स पर, / tmp उपयोगकर्ता के लिए एक निजी निर्देशिका के लिए एक सिम्लिंक है - इसलिए सभी के बाद कोई साझाकरण नहीं है। - Jonathan Leffler
उत्तर के लिए धन्यवाद, मैंने अधिक जानकारी के साथ प्रश्न अद्यतन किया है। - Xeoncross
जोनाथन: चिपचिपा बिट का मतलब केवल निर्देशिका का मालिक है, या फ़ाइल का मालिक, इसका नाम बदल सकता है या हटा सकता है (यानी, निर्देशिका 'फ़ाइल' में अपनी प्रविष्टि पर कार्य करें)। व्यक्तिगत निर्देशिका पर अनुमतियां इन निर्देशिका संचालन के लिए खेल में नहीं आती हैं (rename(), unlink()), केवल फाइल पर ही कार्रवाई के लिए (open())। यह "सामान्य" व्यवहार है। - Phil P


मुझे विश्वास है कि ऐसा करने का सबसे अच्छा तरीका पॉज़िक्स एसीएल का उपयोग कर रहा है। वे काम करने में सहज हैं और आपको आवश्यक सभी कार्यक्षमताओं की पेशकश करते हैं।

http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs

एसीएल का उपयोग करने के लिए यहां एक गाइड है। आपके वितरण के आधार पर आपके कर्नेल में पहले से ही एसीएल समर्थन शामिल हो सकता है।

http://www.cs.unc.edu/cgi-bin/howto?howto=linux-posix-acls


2
2018-03-26 10:44



एसीएल के बारे में उपयोगी जानकारी के लिए +1। हालांकि, मैं कुछ डेवलपर्स के साथ एक साधारण सर्वर को प्रबंधित करने के लिए सिस्टम को अतिरिक्त जंक सिस्टम को बंद नहीं करना चाहता हूं। मैं एसीएल का उपयोग करने के लिए कर्नेल को पुनः संयोजित करने में भी सहज नहीं हूं। - Xeoncross
@ एक्सोनक्रॉस: एसीएल कुछ भी नीचे नहीं दबाता है। वे सामान्य फ़ाइल अनुमतियों की तरह सिर्फ मेटाफॉर्मेशन हैं। यह सब कुछ "अतिरिक्त" और जटिल नहीं है, मेरा मानना ​​है कि यह कुछ भ्रमित चिपचिपा / समूह / जो भी समाधान के बजाय अनुमतियों का प्रबंधन करने का सबसे आसान और सबसे अच्छा तरीका है। डरो मत, बस एसीएल के साथ रिमाउंट करें और इसे आज़माएं! - Tie-fighter


फ़ाइल का मालिक वह व्यक्ति होना चाहिए जो इसे बनाता है, जबकि समूह www-data होना चाहिए। निर्देशिका / फ़ाइलों के लिए मोड सामान्य 755/644 में है। निर्देशिकाओं और फ़ाइलों के लिए समूह को लिखने की आवश्यकता है, तो मोड 775/664 है। मान लें कि धान डेवलपर है। कुल मिलाकर यह बनाता है:

chown -R paddy:www-data /var/www/websiteindevelopment
chmod -R 755 /var/www/websiteindevelopment
chmod -R 775 /var/www/websiteindevelopment/directorywritablebygroup
find /var/www/websiteindevelopment -type f -perm 755 -print -exec chmod 644 {} \;  
find /var/www/websiteindevelopment -type f -perm 775 -print -exec chmod 664 {} \;

1
2017-09-24 18:08





@ ज़ीओनक्रॉस के उत्तर में जोड़कर, मुझे लगता है कि फ़ाइलों और निर्देशिकाओं पर अलग-अलग अनुमतियों को कॉन्फ़िगर करना अच्छा होगा।

sudo find /var/www -type d -exec chmod 775 {} \;  # Change permissions of directories to rwxrwxr-x
sudo find /var/www -type f -exec chmod 664 {} \;  # Change file permissions to rw-rw-r--

यह डेवलपर्स को / var / www के भीतर निर्देशिका बनाने और संशोधित करने की अनुमति देगा। जो महत्वपूर्ण लगता है क्योंकि डेवलपर्स को अतिरिक्त निर्देशिकाएं बनाने या उस निर्देशिका को हटाने की आवश्यकता हो सकती है जिसकी अब आवश्यकता नहीं है।

यह डेवलपर्स को कोड फ़ाइलों को बनाने और संशोधित करने की अनुमति देगा (एचटीएमएल, पीएचपी फाइलें और इसी तरह पढ़ें)। लेकिन, अभी भी केवल हर किसी के लिए केवल पढ़ने के लिए पहुंच की अनुमति होगी।


0
2017-12-09 05:38