शुरुआत में सही तरीके से सेटिंग की अनुमति देने के मामले में मेरे लिए बेल्स द्वारा पोस्ट किया गया समाधान हाजिर है (मैं दूसरी विधि का उपयोग करता हूं), लेकिन इसमें अभी भी लारवेल के लिए संभावित मुद्दे हैं।
डिफ़ॉल्ट रूप से, अपाचे 644 अनुमतियों के साथ फाइलें बनाएगा। इतना कि भंडारण में बहुत कुछ है /। इसलिए, यदि आप स्टोरेज / फ्रेमवर्क / व्यूज की सामग्री को हटाते हैं, तो अपाचे के माध्यम से एक पेज एक्सेस करें। आपको लगेगा कि कैश्ड व्यू आपके द्वारा बनाया गया है:
-rw-r--r-- 1 www-data www-data 1005 Dec 6 09:40 969370d7664df9c5206b90cd7c2c79c2
यदि आप "कारीगर सेवा" चलाते हैं और एक अलग पृष्ठ पर पहुंचते हैं, तो आपको अलग-अलग अनुमतियां मिलेंगी क्योंकि CLI PHP अपाचे से अलग व्यवहार करती है:
-rw-rw-r-- 1 user www-data 16191 Dec 6 09:48 2a1683fac0674d6f8b0b54cbc8579f8e
अपने आप में यह कोई बड़ी बात नहीं है क्योंकि आप उत्पादन में ऐसा नहीं करेंगे। लेकिन अगर अपाचे एक फाइल बनाता है जिसे बाद में उपयोगकर्ता द्वारा लिखा जाना चाहिए, तो यह विफल हो जाएगा। और यह लॉग-इन उपयोगकर्ता और कारीगर का उपयोग करते समय कैश फ़ाइलों, कैश्ड दृश्यों और लॉग पर लागू हो सकता है । एक मुखर उदाहरण "कारीगर कैश: क्लीयर" है जो www-data: www-data 644: किसी भी कैश फ़ाइलों को हटाने में विफल रहेगा।
इसे www-डेटा के रूप में कारीगर कमांड चलाकर आंशिक रूप से कम किया जा सकता है, इसलिए आप सब कुछ जैसे / स्क्रिप्टिंग कर रहे हैं:
sudo -u www-data php artisan cache:clear
या आप इससे होने वाली थकान से बच जाएंगे और इसे अपने .bash_aliases में जोड़ देंगे:
alias art='sudo -u www-data php artisan'
यह काफी अच्छा है और किसी भी तरह से सुरक्षा को प्रभावित नहीं कर रहा है। लेकिन डेवलपमेंट मशीनों पर, रनिंग टेस्टिंग और सैनिटेशन स्क्रिप्ट्स को यह अनकही बना देता है, जब तक कि आप phpunit को चलाने के लिए www sudo -u www-data ’का उपयोग करने के लिए एलियास को स्थापित नहीं करना चाहते हैं और बाकी सब कुछ जो आप अपने बिल्ड की जांच करते हैं, जिससे फाइलें बन सकती हैं।
इसका उपाय यह है कि बेल्स सलाह के दूसरे भाग का पालन करें, और निम्नलिखित को / etc / apache2 / envvars में जोड़ें, और पुनः आरंभ करें (पुनः लोड नहीं करें) Apache:
umask 002
यह अपाचे को डिफ़ॉल्ट रूप से 664 फाइलें बनाने के लिए मजबूर करेगा। अपने आप में, यह एक सुरक्षा जोखिम पेश कर सकता है। हालाँकि, लारवेल वातावरण पर ज्यादातर यहाँ चर्चा की जा रही है (होमस्टेड, वैग्रैंट, उबंटू) वेब सर्वर समूह www-डेटा के तहत उपयोगकर्ता www-data के रूप में चलता है। इसलिए यदि आप मनमाने ढंग से www-data समूह में शामिल होने की अनुमति नहीं देते हैं, तो कोई अतिरिक्त जोखिम नहीं होना चाहिए। यदि कोई व्यक्ति वेबसर्वर से बाहर निकलने का प्रबंधन करता है, तो उनके पास www-डेटा एक्सेस स्तर वैसे भी कुछ भी नहीं खोता है (हालांकि यह सुरक्षा से संबंधित होने का सबसे अच्छा रवैया नहीं है)। इसलिए उत्पादन पर यह अपेक्षाकृत सुरक्षित है, और एकल-उपयोगकर्ता विकास मशीन पर, यह सिर्फ एक मुद्दा नहीं है।
अंततः जैसा कि आपका उपयोगकर्ता www-data समूह में है, और इन फ़ाइलों वाली सभी निर्देशिकाएं g + s हैं (फ़ाइल हमेशा मूल निर्देशिका के समूह के तहत बनाई गई है), उपयोगकर्ता द्वारा बनाई गई कुछ भी या www-डेटा r / होगी दूसरे के लिए डब्ल्यू।
और यही यहाँ उद्देश्य है।
संपादित करें
आगे अनुमतियों को स्थापित करने के लिए उपरोक्त दृष्टिकोण की जांच करने पर, यह अभी भी काफी अच्छा लग रहा है, लेकिन कुछ ट्विक्स मदद कर सकते हैं:
डिफ़ॉल्ट रूप से, निर्देशिकाएं 775 हैं और फाइलें 664 हैं और सभी फाइलों में उपयोगकर्ता का मालिक और समूह है जिन्होंने केवल रूपरेखा स्थापित की है। तो मान लें कि हम उस बिंदु से शुरू करते हैं।
cd /var/www/projectroot
sudo chmod 750 ./
sudo chgrp www-data ./
पहली चीज़ जो हम करते हैं, वह सभी के लिए पहुँच को अवरुद्ध करती है, और समूह को www-data बनाती है। केवल www-डेटा के स्वामी और सदस्य ही निर्देशिका तक पहुँच सकते हैं।
sudo chmod 2775 bootstrap/cache
sudo chgrp -R www-data bootstrap/cache
वेबसर्वर को Services.json और compiled.php बनाने की अनुमति देने के लिए, जैसा कि आधिकारिक Laravel इंस्टॉलेशन गाइड द्वारा सुझाया गया है। समूह चिपचिपा सा सेट करने का मतलब है कि ये www-data के समूह के साथ निर्माता के स्वामित्व में होंगे।
find storage -type d -exec sudo chmod 2775 {} \;
find storage -type f -exec sudo chmod 664 {} \;
sudo chgrp -R www-data storage
हम कैश, लॉग, सत्र और फ़ाइलों को देखने की अनुमति देने के लिए भंडारण फ़ोल्डर के साथ एक ही काम करते हैं। हम निर्देशिकाओं और फ़ाइलों के लिए निर्देशिका अनुमतियों को स्पष्ट रूप से सेट करने के लिए खोज का उपयोग करते हैं। हमें बूटस्ट्रैप / कैश में ऐसा करने की आवश्यकता नहीं थी क्योंकि वहां कोई भी उप-निर्देशिका नहीं है (सामान्य रूप से)।
आपको किसी भी निष्पादन योग्य झंडे को फिर से लगाने, और विक्रेता को हटाने की आवश्यकता हो सकती है / * और फ़ोपुनिट एट अल के लिए लिंक को फिर से बनाने के लिए संगीतकार निर्भरता को पुनर्स्थापित करना, जैसे:
chmod +x .git/hooks/*
rm vendor/*
composer install -o
बस। ऊपर बताए गए अपाचे के लिए umask को छोड़कर, www-डेटा द्वारा पूरे प्रॉजेक्ट को लिखने योग्य बनाने के बिना यह आवश्यक है, जो कि अन्य समाधानों के साथ होता है। इसलिए यह इस तरह से सुरक्षित है कि www-data के रूप में चल रहे एक घुसपैठिए के पास अधिक सीमित लेखन पहुंच है।
अंत संपादित करें
Systemd के लिए परिवर्तन
यह php-fpm के उपयोग पर लागू होता है, लेकिन शायद दूसरों के लिए भी।
मानक systemd सेवा को ओवरराइड करने की आवश्यकता होती है, ओवरराइड.कॉन्फ़ फ़ाइल में umask सेट, और सेवा पुनरारंभ होती है:
sudo systemctl edit php7.0-fpm.service
Use:
[Service]
UMask=0002
Then:
sudo systemctl daemon-reload
sudo systemctl restart php7.0-fpm.service
777है कि बहुत अधिक स्वतंत्रता है, क्योंकि इसमें सभी के लिए सभी अनुमतियां शामिल हैं।