सवाल Apache 2 के उपयोगकर्ता www-data / var / www में अनुमतियों को संभालने का सबसे अच्छा तरीका क्या है?


क्या किसी को फाइलों को संभालने के लिए एक अच्छा समाधान मिला है /var/www? हम नाम आधारित वर्चुअल होस्ट चला रहे हैं और अपाचे 2 उपयोगकर्ता है www-डेटा

हमारे पास दो नियमित उपयोगकर्ता और रूट हैं। तो जब फाइलों के साथ गड़बड़ हो /var/wwwकरने के बजाय ...

chown -R www-data:www-data

... हर समय, इसे संभालने का एक अच्छा तरीका क्या है?

पूरक प्रश्न: फिर आप अनुमतियों पर कितने कट्टरपंथी जाते हैं?

यह हमेशा सहयोगी विकास वातावरण में एक समस्या रही है।


211
2018-05-11 05:13


मूल


और देखें: मेरी वेबसाइट के लिए उपयोग करने के लिए सबसे अच्छी लिनक्स अनुमतियां क्या हैं? - Zoredache


जवाब:


@ ज़ोरर्डैच पर विस्तार करने का प्रयास कर रहा है उत्तर, क्योंकि मैं इसे अपने आप जाने देता हूं:

  • एक नया समूह बनाएं (www-pub) और उस समूह में उपयोगकर्ताओं को जोड़ें

    groupadd www-pub

    usermod -a -G www-pub usera  ## को मौजूदा समूहों में शामिल करने के लिए उपयोग करना चाहिए

    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 = मालिक के लिए आरडब्ल्यूएक्स (रूट), 7 = समूह के लिए आरडब्ल्यूएक्स (www-pub), 5 = दुनिया के लिए आरएक्स (अपाचे www-data उपयोगकर्ता सहित)

    समूह आईडी सेट करें (SETGID) बिट (2) समूह (www-pub) को उस फ़ोल्डर में बनाए गए सभी नई फ़ाइलों / फ़ोल्डर्स में कॉपी करने का कारण बनता है। अन्य विकल्प उपयोगकर्ता आईडी की प्रतिलिपि बनाने के लिए सेट (4) हैं, और स्टिकी (1) जो मुझे लगता है कि केवल मालिक ही फाइलों को हटा देता है।

    वहां एक -R रिकर्सिव विकल्प, लेकिन यह फाइलों और फ़ोल्डर्स के बीच भेदभाव नहीं करेगा, इसलिए आपको करना होगा खोजने का उपयोग करें, इस तरह:

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

  • सभी फ़ाइलों को 0664 में बदलें

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

  • अपने उपयोगकर्ताओं के लिए umask को 0002 में बदलें

    उमास्क डिफ़ॉल्ट फ़ाइल निर्माण अनुमतियों को नियंत्रित करता है, 0002 का मतलब है कि फाइलों में 664 और निर्देशिका 775 होगी। इसे सेट करके (संपादन करके umask के नीचे लाइन /etc/profile मेरे मामले में) का मतलब है कि एक उपयोगकर्ता द्वारा बनाई गई फाइलों को बिना किसी आवश्यकता के www-group में अन्य उपयोगकर्ताओं द्वारा लिखने योग्य होगा chmod उन्हें।

फ़ाइल और निर्देशिका बनाकर और मालिक, समूह और अनुमतियों को सत्यापित करके यह सब जांचें ls -l

नोट: आपके समूहों को प्रभावी होने के लिए आपको लॉगआउट / इन करना होगा!


201
2017-09-15 05:11



@ टॉम ग्रेट यह देखने के लिए कि आप इसका उपयोग करने की सलाह देते हैं findइसके लिए आदेश। यदि आपके पास बहुत सी फाइलें / निर्देशिकाएं हैं और आप जीएनयू खोज का उपयोग कर रहे हैं तो इसका उपयोग करने के लिए एक छोटी सी प्रदर्शन युक्ति होगी + के बजाय \; ताकि आदेश होगा एकाधिक फाइलों पर काम करें इसलिये "प्रति फ़ाइल एक बार की बजाय, एक समय में जितनी संभव हो उतनी फाइलों पर कमांड चलाने के लिए तेज़ है। ऐसा करने से प्रत्येक बार कमांड शुरू करने में समय लगता है।" साथ ही, टाइप करना आसान है क्योंकि इसे बैकस्लैश की आवश्यकता नहीं है। - aculich
@ Aculich के सुझाव के साथ अपडेट किया गया + नहीं \; - Tom
@SunnyJ। इसे आज़माएं (बाहरी उद्धरणों के बिना): "ढूंढें / var / www -type f -exec chmod 0664 '{}' \ +" कोशिश करें। '{}' और \ + के बीच एक जगह है। - Buttle Butkus
@ टॉम-इसे तोड़ने का तरीका, धन्यवाद। बस एक नोट- मुझे लगता है कि "उपयोगकर्ता आईडी की प्रतिलिपि बनाने के लिए SETUID (4)" जैसा कि आपके उत्तर में शामिल है गलत है- लिनक्स / यूनिक्स में निर्देशिकाओं पर लागू होने पर SETUID को अनदेखा किया जाता है - रेफरी - 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 होगी। अपाचे को 'अन्य उपयोगकर्ताओं' घटक के माध्यम से सबकुछ तक पहुंच प्राप्त होगी। निर्देशिकाओं पर SETGID बिट फ़ोल्डर के स्वामित्व वाले समूह द्वारा स्वामित्व वाली सभी फ़ाइलों को मजबूर कर देगा। उमास्क को समायोजित करने के लिए यह सुनिश्चित करने के लिए आवश्यक है कि लिखना बिट सेट किया गया है ताकि समूह में कोई भी फाइल संपादित कर सके।

मैं कितने कट्टरपंथियों पर अनुमति देता हूं। यह पूरी तरह से साइट / सर्वर पर निर्भर करता है। अगर केवल 1-2 संपादक हैं और मुझे उन्हें चीजों को तोड़ने से रोकने की ज़रूरत है तो मैं आसान हो जाऊंगा। अगर व्यापार को कुछ और जटिल की आवश्यकता होती है तो मैं कुछ और जटिल स्थापित करूँगा।


59
2018-05-11 05:49



संभावित जोड़ - सेट कैश / अपलोड डीआईआर जिन्हें वेबसर्वर द्वारा www-data: www-data और 775 पर लिखा जाना आवश्यक है। - gacrux
क्या यह उपयोगकर्ताओं को 'अन्य' अनुमतियों पर निर्भर रहने के बजाय अपाचे समूह में जोड़ने के लिए भी काम करेगा? यदि आप जो भी कर रहे हैं वह फाइल अपलोड कर रहा है और उन फ़ाइलों को अपाचे द्वारा पठनीय करने की आवश्यकता है, तो तीसरे समूह को केवल तभी उपयोगी लगता है जब आपको उन फ़ाइलों को संपादित करने की आवश्यकता हो। - Simurr
किसी भी मौके पर आप इसे थोड़ा @ ज़ोरर्डैच का विस्तार कर सकते हैं? मैं rwx बिट्स, chmod, chown, adduser, usermod का मूल उपयोग grok, लेकिन आप मुझे ऑक्टल अनुमतियों, umasks और सब कुछ पर अतिरिक्त पहले अंक के साथ खो दिया है। आपके उल्लिखित दृष्टिकोण को चित्रित करने वाले कुछ नमूना आदेशों की बहुत सराहना की जाएगी। - Tom
इस तरह हर उपयोगकर्ता हर दूसरे उपयोगकर्ता फ़ाइलों तक पहुंच सकता है! इसका मतलब है कि उपयोगकर्ता ए उपयोगकर्ता के config.php को पढ़ सकता है ... उदाहरण के लिए, अपने mysql क्रेडेंशियल को रोक रहा है - drAlberT
एसीएल का उपयोग करके आप सुरक्षा और सहयोगी दोनों को संभालने में सक्षम हो सकते हैं :) - 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
जीत +1 के लिए एसीएल ... और देखने के लिए serverfault.com/a/360120/41823 - Yarin
मुझे आश्चर्य है कि एसीएल बनाम बुनियादी अनुमतियों के लिए कोई प्रदर्शन नकारात्मक है या नहीं। - Buttle Butkus
दुर्भाग्यवश, मानक प्रतिष्ठानों / वितरणों पर एसीएल अक्सर गायब होता है। मेरे द्वारा प्रबंधित किए जाने वाले प्रत्येक सर्वर पर कर्नेल संकलित करना, या बदतर, कभी-कभी फाइल सिस्टम को बदलना दर्द होता है। प्लस बैकअप लेने पर आपको बहुत सावधान रहना चाहिए, खासकर यदि आप सर्वर स्विच कर रहे हैं। एसीएल बहुत अच्छा है लेकिन इसका वर्तमान समर्थन इतना कम है कि मैं इसके खिलाफ किसी भी ऐसे व्यक्ति के लिए अनुशंसा करता हूं जिसके पास सर्वर और आसपास के हर चीज पर पूर्ण नियंत्रण नहीं है। लेकिन एसीएल को इंगित करने के लिए +1 जहां यह वास्तव में समझ में आता है! - Ninj
अच्छा जवाब +1; अपाचे प्रक्रिया को पढ़ने / लिखने की अनुमतियों को बदलने के बारे में एक नोट (www-data उदाहरण के लिए) केवल पूरी साइट के लिए पढ़ने के लिए (setfacl या chmod - या दोनों के माध्यम से) -> यह स्पष्ट रूप से सभी लिखने को अवरोधित करेगा (उदाहरण के लिए अधिकांश सीएमएस पर ब्राउज़र पक्ष से प्लगइन / मॉड्यूल अपलोड / अपडेट करना)। मेरा मानना ​​है कि कई लोकप्रिय लोग भी उपयोगकर्ता स्तर स्तर पर समूह स्तर पर लेखन पहुंच के लिए परीक्षण नहीं करते हैं। आप अभी भी अपडेट कर सकते हैं, लेकिन अपडेट मैन्युअल रूप से लागू किए जाने चाहिए और लिखने वाले फ़ोल्डर्स (लॉग / अस्थायी / अपलोड / आदि) के लिए कोई कस्टम अनुमतियां लागू की जानी चाहिए। केवल पढ़ने के लिए ही बड़ी सुरक्षा है यदि आपकी साइट इसके साथ काम करती है .. अधिक से अधिक नहीं। - bshea


यह सवाल था फिर से पूछा, और जैसे चर्चा की मेटा पर, वर्तमान सर्वोत्तम प्रथा 200 9 में उपलब्ध होने के मुकाबले बेहतर दृष्टिकोण प्रदान करती है, जब यह पूछा गया था। यह उत्तर कुछ मौजूदा समाधान देने की कोशिश करता है सहयोगी वेब विकास वातावरण को सुरक्षित रूप से संभालना


एक सुरक्षित वेब सर्वर और सहयोगी विकास के लिए केवल फ़ाइल अनुमतियों से अधिक है:

  • प्रत्येक साइट के लिए अलग उपयोगकर्ता है यानी सभी साइटों का उपयोग नहीं करते हैं www-data। यह महत्वपूर्ण है, क्योंकि आजकल अपाचे शायद ही कभी सेवा कर रहा है स्थिर सामग्री फाइलें, लेकिन चल रहा है गतिशील वेब साइटें यह उत्तर PHP पर केंद्रित है क्योंकि यह है सबसे आम सर्वर-साइट भाषा, लेकिन वही सिद्धांत दूसरों पर भी लागू होते हैं।

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

  • उपयोग एसएसएच फाइल ट्रांसफर प्रोटोकॉल (SFTP)। सुरक्षा के लिए एफ़टीपी का उपयोग छोड़ दिया जाना चाहिए (क्योंकि यह पासवर्ड और सादे पाठ में सामग्री दोनों भेजता है), यह सुरक्षित विकल्प है एसएफटीपी में एक सुविधा भी है जो सहयोगी वेब विकास के लिए एक आदर्श समाधान है।

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

    प्रत्येक डेवलपर कीपैयर उत्पन्न कर सकता है और निजी कुंजी गुप्त रख सकता है। फिर, सार्वजनिक कुंजी को जोड़ा जाता है ~/.ssh/authorized_keys प्रत्येक वेबसाइट उपयोगकर्ता खाते के लिए फ़ाइल डेवलपर काम कर रहा है। पासवर्ड और लॉगिन के प्रबंधन के लिए इसमें कई फायदे हैं:

    • प्रत्येक डेवलपर को बोझ के बिना उपयोगकर्ता-प्रति-साइट व्यवस्था से जुड़े सभी पासवर्ड याद रखने या स्टोर करने के लिए किसी भी वेबसाइट पर पहुंच प्राप्त हो सकती है।

    • जब भी कोई कंपनी छोड़ देता है तो पासवर्ड बदलने और साझा करने की आवश्यकता नहीं होती है।

    • आप बहुत मजबूत पासवर्ड का उपयोग कर सकते हैं या पासवर्ड आधारित लॉगिन को पूरी तरह अक्षम कर सकते हैं।

  • PHP-FPM का उपयोग करें। उपयोगकर्ता के रूप में PHP चलाने के लिए यह वर्तमान दृष्टिकोण है। कोई नया बनाएं पूल प्रत्येक उपयोगकर्ता के लिए प्रत्येक साइट पर एक पूल। सुरक्षा और प्रदर्शन दोनों के लिए यह सबसे अच्छा है, क्योंकि आप यह भी निर्दिष्ट कर सकते हैं कि एक साइट कितनी संसाधनों का उपभोग कर सकती है।

    उदाहरण देखें NeverEndingSecurity के अलग उपयोगकर्ता / यूआईडी और लिनक्स पर समूह के साथ php-fpm चलाएं। HowtoForge की तरह ट्यूटोरियल हैं उबंटू 16.04 पर अपाचे के साथ PHP-FPM का उपयोग करना जो उपयोगकर्ता के अलग-अलग माध्यम से सुरक्षा बढ़ाने के लिए PHP-FPM का उपयोग नहीं करता है, सर्वर पर एक एकल एफपीएम सॉकेट का उपयोग करने के लिए मार्गदर्शन करता है।


7
2018-05-10 10:03





लोकप्रिय प्रश्न

मैं कैसे पता लगा सकता हूं कि मेरे ec2 भंडारण का कौन सा हिस्सा क्षणिक है विंडोज स्थानीय उपयोगकर्ता बनाने के लिए कमांड लाइन सिंटेक्स क्या है और उस उपयोगकर्ता को स्थानीय समूह में जोड़ें? मैं अपने एसएसडी को एन्क्रिप्ट कैसे कर सकता हूं लेकिन अभी भी अनुपयुक्त (लिनक्स) बूट कर सकता हूं? [बन्द है] प्रोग्रामर से विंडोज सर्वर 2003/2008 रिलीज (आर 1 या आर 2) का पता कैसे लगाएं? उत्तर: क्या मैं कुछ फाइल मौजूद नहीं होने पर vars_files का उपयोग कर सकता हूं लिनक्स पर PHP: इंटरनेट से कनेक्ट करने के लिए PHP का उपयोग प्रॉक्सी सेटिंग्स कैसे करें? 2 जीबी रैम E6500 सीपीयू पर एक दिन 10 के + वर्डप्रेस विचारों के लिए अपाचे अनुकूलित करें