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

Question

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

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

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

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

2. डेवलपर्स

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

---

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

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

1. स्रोत नियंत्रण जैसे git या svn
2. "वेबसाइट" जैसे समूह में उपयोगकर्ता ( या "www-data" में भी जोड़े गए )
3. अपाचे या लाइटवेट जैसे सर्वर
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 निर्देशिका को हासिल करने और प्रबंधित करने का सबसे अच्छा तरीका है वह जीतता है।

Answer 1

अधिक शोध के बाद ऐसा लगता है कि इसका उत्तर देने के लिए एक और (संभवतः बेहतर तरीका) 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जो भी उपयोगकर्ता इसे कॉल कर रहा है, उसके रूप में चलता है, तब तक जब तक उपयोगकर्ता "डेवलपर" समूह में होता है, तो उन्हें फ़ोल्डर्स बनाने, पीएचपी फ़ाइलों को संपादित करने और गिट रिपॉजिटरी का प्रबंधन करने में सक्षम होना चाहिए।

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

Comments

मुझे उचित लगता है।

— वाज़ोक्स

अच्छा। शायद अगर मैं इस जोड़े के साथ इस बात की पुष्टि कर सकता हूं कि मैं इस दृष्टिकोण का उपयोग करूंगा। यह सबसे अच्छा जवाब लगता है जो मैं लोगों को निचोड़ने में सक्षम रहा हूं।

— Xeoncross

आप निर्दिष्ट नहीं कर रहे हैं कि फ़ाइलों का स्वामी कौन होगा। क्या आप इसे जड़ के रूप में छोड़ देंगे? तब केवल sudoers आपके अपलोड फ़ोल्डर को संपादित कर सकते हैं (शायद आपका इरादा नहीं है)।

— निक

हाँ, जड़ मालिक रहेगा। हालाँकि, चूंकि समूह का मालिक अब "डेवलपर" है (और उसके पास wrx अनुमति है) तो सभी देवता (और अपाचे / nginx) भी पढ़ सकते हैं। सूदो की जरूरत नहीं।

— Xeoncross

Umask देखने के लिए एक और चीज है। कई प्रणालियों में 022 का डिफ़ॉल्ट umask है जो नई फ़ाइलों पर समूह और सार्वजनिक दोनों के लिए लेखन अनुमति को हटा देगा। मुझे संदेह है कि आप 002 (जनता के लिए कोई लेखन नहीं) या 007 (जनता के लिए कोई पहुंच नहीं) चाहते हैं। आप किसी भी प्रक्रिया के लिए Apache के विन्यास और / या स्टार्टअप स्क्रिप्ट में umask सेट कर सकते हैं जिसे निर्देशिका तक पहुंचने की आवश्यकता है। इसे / etc / प्रोफाइल या / etc / bashrc में जोड़ना न भूलें ताकि यह आपके डेवलपर्स के लिए भी डिफ़ॉल्ट रूप से सेट हो जाए

— मार्क पोर्टर

Answer 2

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

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

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

Comments

Git / svn या PHP नए फ़ोल्डर कैसे बनाता है?

— Xeoncross

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

— निक

जाहिरा तौर पर गिट इसे चलाने वाले उपयोगकर्ता के रूप में चलता है - किसी भी अन्य उपकरण की तरह।

— Xeoncross

फिर अपाचे समूह में git उपयोगकर्ता को जोड़ें और फ़ोल्डर समूह को लिखने की अनुमति दें।

— डेविड रिकमैन

मैंने अभी कहा, git के पास एक उपयोगकर्ता नहीं है - यह वर्तमान उपयोगकर्ता के रूप में उपयोग करता है।

— Xeoncross

Answer 3

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

Git अनुमतियाँ हल की गईं।

उपयोगकर्ता अनुमतियाँ उन सभी उपयोगकर्ताओं को जोड़कर हल करने योग्य लगती हैं जिन्हें www निर्देशिका तक पहुंच की आवश्यकता होती है www-dataजो अपाचे (और 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 (रीड / राइट / एक्ज़ीक्यूट) फ़ाइलों और निर्देशिकाओं को rwx कर सकें ( कोई और भी इसे एक्सेस करने में सक्षम नहीं होना चाहिए )।

sudo chmod -R 2770 /var/www

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

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

Comments

मुझे PHP द्वारा सभी वेब फ़ाइलों को लिखने योग्य होने का विचार पसंद नहीं है, अगर स्क्रिप्ट की भेद्यता है तो यह आपके संभावित जोखिम को बढ़ाता है।

— निक

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

— Xeoncross

स्क्रिप्ट और डेटा को अलग रखने की कोशिश करें। यहां तक ​​कि अगर कोई हमलावर / अपलोड / में कुछ गिराने का प्रबंधन करता है, तो उसे निष्पादन योग्य नहीं होना चाहिए। परतों में सुरक्षा प्रमुख है।

— निक

Answer 4

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

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

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

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

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

Comments

अच्छा उत्तर। MacOS X पर, सिस्टम ऐसा व्यवहार करता है मानो SGID बिट स्वचालित रूप से निर्देशिकाओं पर है। चिपचिपा सा मतलब आमतौर पर आप केवल फ़ाइल को हटा सकते हैं यदि आप इसे लिख सकते हैं। अर्थात्, कोई भी सार्वजनिक रूप से लिखने योग्य फ़ाइल को / tmp में निकाल सकता है। MacOS X पर, / tmp उपयोगकर्ता के लिए एक निजी निर्देशिका के लिए एक सहानुभूति है - इसलिए सभी के बाद कोई साझाकरण नहीं है।

— जोनाथन लेफ़लर

उत्तर के लिए धन्यवाद, मैंने अधिक जानकारी के साथ प्रश्न को अपडेट किया है।

— Xeoncross

जोनाथन: चिपचिपा बिट का मतलब केवल निर्देशिका का मालिक, या फ़ाइल का मालिक है, इसका नाम बदल सकता है या हटा सकता है (यानी, निर्देशिका 'फ़ाइल' में इसके प्रवेश पर कार्य करता है)। व्यक्तिगत फ़ाइल पर अनुमतियाँ इन निर्देशिका कार्यों ( rename(), unlink()), केवल फ़ाइल पर कार्रवाई के लिए ( open()) के लिए नहीं आती हैं । यह "सामान्य" व्यवहार है।

— फिल पी।

Answer 5

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

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

Comments

ACL के बारे में उपयोगी जानकारी के लिए +1। हालाँकि, मैं नहीं चाहता कि अतिरिक्त जंक सिस्टम को नीचे गिराया जाए ताकि सिंपल सर्वर को कुछ डेवलपर्स के साथ मैनेज किया जा सके। मैं ACL का उपयोग करने के लिए कर्नेल को फिर से जोड़ने के साथ सहज नहीं हूं।

— Xeoncross

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

— टाई-फाइटर

Answer 6

फ़ाइल का स्वामी वह व्यक्ति होना चाहिए जो इसे बनाता है, जबकि समूह को 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 {} \;

Answer 7

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

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 के भीतर निर्देशिका बनाने और संशोधित करने की अनुमति देगा। जो महत्वपूर्ण लगता है क्योंकि, डेवलपर्स को अतिरिक्त निर्देशिकाएं बनाने या एक निर्देशिका को हटाने की आवश्यकता हो सकती है जिसकी अब आवश्यकता नहीं है।

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