सामान्य वेब प्रोजेक्ट निर्देशिकाओं के लिए एकदम सही यूनिक्स अनुमतियां क्या हैं?


12

लिखित वेब अनुप्रयोग में अनुसरण के लिए अष्टक प्रारूप में सही न्यूनतम अनुमतियाँ क्या हैं?

  1. एक निर्देशिका जहां उपयोगकर्ता अपलोड की गई स्थिर फाइलें (चित्र / swf / js फ़ाइलें) निवास करेगा
  2. एक निर्देशिका जहाँ व्यवस्थापक अपलोड की गई स्थिर फाइलें (चित्र / swf / js फ़ाइलें) निवास करेगा
  3. एक निर्देशिका जहाँ पुस्तकालयों का उपयोग अनुप्रयोग में होता है
  4. एक निर्देशिका जहां निष्पादन योग्य / ब्राउज़ करने योग्य सर्वर साइड स्क्रिप्ट रहते हैं
  5. एक निर्देशिका जहां पहले से मौजूद फाइलें (txt या xml) को सर्वर साइड पर कोड द्वारा संपादित किया जाएगा

यहाँ मेरे सुझाव और औचित्य हैं

  1. 555, हर कोई पढ़ और लिख सकता है, कोई भी निष्पादित नहीं कर सकता है
  2. 544, मालिक अकेले लिख सकता है, बाकी सभी केवल पढ़ सकते हैं, कोई भी निष्पादित नहीं कर सकता है
  3. 000, किसी को पढ़ने, लिखने और न ही निष्पादित करने की आवश्यकता है, केवल वेब सर्वर द्वारा उपयोग किया जाएगा?
  4. 661, मालिक पढ़ सकते हैं, लिख सकते हैं, बाकी सभी केवल निष्पादित कर सकते हैं
  5. 600, मालिक पढ़ सकता है, लिख सकता है (आवश्यकता नहीं हो सकती है), कोई और कुछ भी नहीं कर सकता है

अब मुझे दो चीजों में दिलचस्पी है:

  1. क्या वेब आधारित अनुप्रयोगों में आमतौर पर उपयोग की जाने वाली कोई चीज है जिसे मैंने पहली सूची में याद किया है?
  2. क्या आप दूसरी सूची में असहमत हैं, आपके पास क्या विकल्प है और यह बेहतर क्यों है?

1
मुझे समझ में नहीं आता कि लोग इन दिनों ACLs का उपयोग क्यों नहीं कर रहे हैं ...
pfo

जवाबों:


20

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

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

लिनक्स पर, उपयोगकर्ता समूहों से संबंधित होते हैं - हम किसी उपयोगकर्ता को दूसरे समूह में जोड़ सकते हैं और उस समूह को विशेषाधिकार प्रदान कर सकते हैं।

एक अच्छा सेटअप आपके सर्वर को एक उपयोगकर्ता के रूप में चलाएगा (चलो इस उपयोगकर्ता को 'वेबसर्वर' कहते हैं) और आपकी डायनामिक स्क्रिप्टिंग भाषा रन (उदाहरण के लिए FastCGI) अपने स्वयं के उपयोगकर्ता के रूप में (प्रति साइट एक उपयोगकर्ता - चलो हमारे पहले उपयोगकर्ता को 'site1' कहते हैं) ।

आपकी फ़ाइलों की सेवा के लिए, वेबसर्वर को उन तक पहुंच की आवश्यकता होती है, और स्क्रिप्टिंग भाषा को उन तक पहुंच की आवश्यकता होती है। इसका मतलब है: 'site1' और 'webserver' को आपकी फ़ाइलों को पढ़ने में सक्षम होना चाहिए। उनमें से केवल एक, हालांकि फाइलों को 'खुद' कर सकते हैं। स्वामी 'उपयोगकर्ता' (उपयोगकर्ता, समूह, अन्य में) है। हमें अपनी स्क्रिप्टिंग भाषा की भी आवश्यकता है ताकि निर्देशिका को लिखने में सक्षम हो (और जो फाइलें लिखी हैं, उन्हें पढ़ें)। इसलिए उपयोगकर्ता 'साइट 1' को पढ़ने और लिखने की अनुमति चाहिए। चूंकि हम चाहते हैं कि समूह और अन्य अनुमतियाँ यथासंभव प्रतिबंधात्मक हों, हमारा 'स्वामी' 'साइट 1' होगा, और संबंधित उपयोगकर्ता अनुमतियाँ पढ़ी और लिखी जाएंगी।

चूंकि हम अपने वेबसर्वर के लिए किसी अन्य 'उपयोगकर्ता' के रूप में अनुमतियों को निर्दिष्ट नहीं कर सकते हैं, हम 'वेबसर्वर' को 'साइट 1' समूह में जोड़ देंगे (आप निश्चित रूप से, 'साइट 1' और 'वेबसर्वर' दोनों के साथ एक अलग समूह बना सकते हैं।) इस समूह के सदस्यों को एक ही अनुमति दी जाएगी। अपनी अनुमतियों का निर्धारण करने के लिए किसी भी उपयोगकर्ता को सबसे लक्स अनुमतियाँ (उपयोगकर्ता, समूह, अन्य सेट) लागू की जाएंगी।

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

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

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

इसलिए, न्यूनतम फ़ाइल अनुमतियां हो सकती हैं:

  • एक निर्देशिका में एक फ़ाइल जहाँ उपयोगकर्ता अपलोड की गई स्थिर फाइलें (चित्र / swf / js फ़ाइलें) निवास करेगा: 640
  • निर्देशिका में एक फ़ाइल जहाँ व्यवस्थापक अपलोड की गई स्थिर फ़ाइलें (चित्र / swf / js फ़ाइलें) निवास करेगा: 640
  • निर्देशिका में एक फ़ाइल जहाँ अनुप्रयोग में उपयोग किए जाने वाले पुस्तकालय रहते हैं: 400 (या 440)
  • निर्देशिका में एक फ़ाइल जहाँ निष्पादन योग्य / ब्राउज़ करने योग्य सर्वर साइड स्क्रिप्ट्स का निवास होगा: 400 (या 440)
  • एक निर्देशिका में एक फ़ाइल जहां पहले से मौजूद फ़ाइलें (txt या xml) को सर्वर साइड: 640 या 600 पर कोड द्वारा संपादित किया जाएगा
    • (इस बात पर निर्भर करता है कि वेब सर्वर इन्हें कब प्रदर्शित करेगा, अनमॉडिफाइड कई बार)

जबकि, न्यूनतम निर्देशिका अनुमतियां हो सकती हैं:

  • एक निर्देशिका जहां उपयोगकर्ता अपलोड की गई स्थिर फाइलें (चित्र / swf / js फ़ाइलें) निवास करेगा: 750
  • एक निर्देशिका जहाँ व्यवस्थापक अपलोड की गई स्थिर फाइलें (चित्र / swf / js फ़ाइलें) निवास करेगा: 750
  • एक निर्देशिका जहां पुस्तकालयों का उपयोग अनुप्रयोग में होता है: 500 (या 550) [510 होना चाहिए कम से कम]
  • एक निर्देशिका जहां निष्पादन योग्य / ब्राउज़ करने योग्य सर्वर साइड स्क्रिप्ट रहते हैं: 500 (या 550) [510 कम से कम होना चाहिए]
  • एक निर्देशिका जहां पहले से मौजूद फाइलें (txt या xml) को सर्वर साइड: 750 या 700 पर कोड द्वारा संपादित किया जाएगा
    • (यह निर्भर करता है कि वेब सर्वर यहां से फाइलों की सेवा करेगा, कभी-कभी अनमॉडिफाइड)

एक बार फिर से - आपके वेब सर्वर के पास हर उस निर्देशिका के ऊपर 'निष्पादित' अनुमतियाँ होनी चाहिए, जिसके लिए उसे एक्सेस की आवश्यकता होती है - इसलिए भले ही वेब सर्वर किसी दिए गए निर्देशिका से फ़ाइलों की सेवा नहीं करेगा, हमें इसे अनुमति अनुमतियाँ प्रदान करनी चाहिए।

वेब सर्वर को अधिकांश फाइलों तक पहुंच प्रदान करना काफी आम है (इसलिए उन 500 को 550 में बदलें)। डिफ़ॉल्ट 'कुछ हद तक सुरक्षित' अनुमतियाँ आमतौर पर निर्देशिकाओं के लिए 755 और फ़ाइलों के लिए 644 हैं - कोई निष्पादन अनुमतियाँ नहीं, हर कोई पढ़ सकता है, और केवल उपयोगकर्ता लिख ​​सकता है - आप ध्यान देंगे कि किसी लिनक्स सिस्टम पर अधिकांश फ़ाइलों में ये अनुमतियाँ हैं।

ध्यान रखें कि 'अन्य' अनुमतियाँ किसी भी सिस्टम उपयोगकर्ता को संदर्भित करती हैं जो स्वामी या समूह में नहीं है (अर्थात सभी शेष सिस्टम उपयोगकर्ता)। अपनी 'अन्य' अनुमतियों को प्रतिबंधित रखना अच्छा है, क्योंकि ये उपयोगकर्ता अज्ञात हैं - आपने उन्हें स्पष्ट रूप से अनुमति नहीं दी है। अन्य अनुमतियाँ अक्सर एक समझौता प्रणाली पर लाभ उठाने के लिए सबसे आसान होती हैं (उदाहरण के लिए / tmp एक सामान्य लक्ष्य है)।

उपरोक्त के संदर्भ में, मुझे नहीं लगता कि आपके अंतिम दो प्रश्न प्रासंगिक हैं। अपनी निर्देशिका अनुमतियाँ 550 (और फ़ाइल अनुमतियाँ 440) पर सेट करें, और उसके बाद उपयोगकर्ता को अनुमति दें कि आपके एप्लिकेशन को जो भी निर्देशिकाएँ लिखनी हैं (यानी निर्देशिका: 750; फ़ाइल; 640)।

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


@ मुख्य: बिल्कुल - उस पल में फ़ाइल अनुमतियों के बारे में सोच रहा था - उस को ठीक करेगा - धन्यवाद।
साइबरबरी

1

काम पूरा करने के लिए अनुमतियों का न्यूनतम सेट होना सामान्य है। यदि आपके पास आपका वेबसर्वर है और उपयोगकर्ता एक साझा समूह साझा करते हैं तो आप किसी भी एक्सेस को देने की आवश्यकता को दूर कर सकते हैं o। अनुमतियाँ भी उपयोगकर्ताओं से संबंधित हैं। आप अष्टाधारी अनुमतियों को गलत समझते हैं।

  1. 555 r-xr-xr-xनहीं है rw-rw-rw। जैसा कि यह एक निर्देशिका है तो फ़ाइलों को बनाने / हटाने के लिए जो आपको xसेट करने की आवश्यकता होती है, इसलिए 750 rwxr-x---को शुरू करने के लिए एक अच्छी जगह होगी। यह उस उपयोगकर्ता को अनुमति देता है जो फ़ाइलों को जोड़ने और हटाने के लिए सामान्य समूह में निर्देशिका का मालिक है / उन्हें एक्सेस करने के लिए।
  2. वही 1. ऊपर।
  3. यदि वे वास्तव में 050 की तुलना में स्थिर फाइलें हैं, तो वेब सर्वर को एक्सेस देने के लिए हालांकि पहले स्थान पर फाइलें बनाने के लिए 750 न्यूनतम होगा।
  4. ऊपर 3 के समान।
  5. 070 वेबसर्वर को फ़ाइलों को पढ़ने और बदलने की अनुमति देने के लिए न्यूनतम होगा लेकिन फ़ाइलों को बनाने की आवश्यकता है इसलिए 770 संभवतः अधिक यथार्थवादी है।

क्या वेब सर्वर को फ़ाइलों को पढ़ने के लिए निर्देशिका पर अनुमति की आवश्यकता नहीं होगी (अंक # 1 (740?), 3, 5)?
साइबरबरी ६

रवींद्र! वास्तव में x को फ़ाइलों तक पहुँचने की आवश्यकता है r बस आपको उन्हें सूचीबद्ध करने की अनुमति देता है ... अधिक कॉफी के लिए बंद करता है।
user9517

0

सामान्य तौर पर एक मोड का उपयोग करें 0755, 0775 या 2775 निर्देशिकाओं पर (निर्देशिकाओं पर SGID बिट, BSD के लिए और Linux के लिए यदि BSD शब्दार्थ के साथ फाइलसिस्टम माउंट किया गया है, तो नई फाइलों का समूह जुड़ाव माता-पिता की निर्देशिका के बजाय मेल खाता है, तब फ़ाइल के निर्माता का डिफ़ॉल्ट GID)। यह सभी उपयोगकर्ताओं को ट्रैविस (chdir में और उसके माध्यम से) की अनुमति देता है और पढ़ता है (ls कमांड चलाता है या रीडडीर / रीड सिस्टम कॉल करता है) निर्देशिकाओं को विचाराधीन करता है। विकल्प समूह / लेखन विकल्प जोड़ते हैं और, जैसा कि नोट किया गया है, निर्देशिकाओं पर SGID बिट, एक उपयुक्त समूह से जुड़ी सभी फाइलों और उपनिर्देशिकाओं को रखने में मदद कर सकता है।

फ़ाइलों के लिए आमतौर पर 0644 या संभवतः 0664 (दुनिया में पढ़ने योग्य और या तो समूह लेखन योग्य या नहीं) का उपयोग किया जाएगा। स्पष्ट रूप से सीजीआई लिपियों और बायनेरिज़ के लिए एक्स-बिट को जोड़ना होगा; और कुछ विशेष स्थितियों के लिए, बहुत अच्छी तरह से परीक्षण किए गए बायनेरिज़ के साथ, कोई SUID या SGID बिट्स जोड़ सकता है। आम तौर पर यूनिक्स और लिनक्स स्क्रिप्ट्स पर SUID / SGID बिट को नजरअंदाज करेंगे और केवल मूल संकलित, निष्पादन योग्य बायनेरिज़ के लिए इसके शब्दार्थ को सम्मानित करेंगे। हालाँकि आप अपनी साइट को अपाचे जैसे कुछ मॉड्यूल जैसे "सेतुइधाक" के साथ चला रहे होंगे, जिसका उपयोग वेब सर्वर को एसयूआईडी / एसजीआईडी ​​बिट्स की व्याख्या की गई लिपियों पर भी करने के लिए किया जा सकता है। (यह HTTP डेमॉन स्टेट द्वारा किया जाता है) (प्रत्येक फाइल को आईएनजी और अपने स्वयं के कस्टम फोर्क () / निष्पादित () कोड का उपयोग करके, सही ढंग से इंटरप्रेटर स्ट्रिंग को निष्पादित करने के लिए प्रक्षेपित करते हुए) () वेक्टर केवल निष्पादन योग्य पास करने के बजाय।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.