Linux drwxr-xr-x permissions का क्या अर्थ है

drwxr-xr-x का अर्थ

drwxr-xr-x एक ऐसी directory को दर्शाता है जिसे उसका मालिक बदल सकता है, और जिसे अन्य सभी users पढ़ सकते हैं और उसके अंदर जा सकते हैं, बिना उसमें कोई बदलाव किए। Octal में यह mode 755 होता है। Linux हर ls -l output की प्रत्येक पंक्ति की शुरुआत में ये दस characters print करता है, और इनका अर्थ हमेशा एक ही क्रम में समान रहता है, इसलिए एक string को सीखने से आप उन सभी को समझ जाते हैं।

एक नियम बाकी सभी से पहले आता है, क्योंकि यह तय करता है कि आपकी अपनी testing आपको कुछ बताती है या नहीं। root user permission bits को अनदेखा करता है। Kernel root को CAP_DAC_OVERRIDE capability (discretionary access control override) प्रदान करता है, इसलिए root उन files को खोल लेता है जिनका mode उन्हें मना करता है। इस पृष्ठ पर दिया गया हर उदाहरण root के लिए सफल होता है, चाहे bits कुछ भी कहें। जब आप नियमों को काम करते हुए देखना चाहते हैं, तो एक सामान्य user के रूप में log in करें।

दस अक्षर, एक-एक करके

एक directory और एक file बनाएँ जिन्हें देखा जा सके। यहाँ कुछ भी नई directory के बाहर किसी चीज़ को प्रभावित नहीं करता है।

mkdir -p ~/permdemo/inner
printf 'hello\n' > ~/permdemo/inner/notes.txt
ls -ld ~/permdemo ~/permdemo/inner ~/permdemo/inner/notes.txt

022 के सामान्य default umask के साथ, दो directory लाइनें drwxr-xr-x से शुरू होती हैं और file लाइन -rw-r--r-- से शुरू होती है।

पहला अक्षर file का प्रकार है, permission नहीं। d एक directory है। - एक सामान्य file है। l एक symbolic link है। c और b character और block device nodes हैं। s एक socket है, और p एक named pipe है। यह octal मान के बाहर स्थित होता है, यही कारण है कि drwxr-xr-x, d से शुरू होने के बजाय 755 हो जाता है।

इसके बाद के नौ अक्षर तीन-तीन के समूह हैं, और उनका क्रम कभी नहीं बदलता है।

• अक्षर 2 से 4 owner triad हैं, वे bits जो उस user पर लागू होते हैं जिसके पास file का स्वामित्व है।
• अक्षर 5 से 7 group triad हैं, वे bits जो file के group पर लागू होते हैं।
• अक्षर 8 से 10 other triad हैं, वे bits जो बाकी सभी पर लागू होते हैं।

एक triad के भीतर slots हमेशा r, फिर w, फिर x होते हैं, और एक डैश का मतलब है कि वह bit बंद है। अक्षर कभी अपनी स्थिति नहीं बदलते। r-x का अर्थ है write के बिना read। -w- का अर्थ है read के बिना write, जो कानूनी है लेकिन दुर्लभ है।

इसलिए drwxr-xr-x इस प्रकार विभाजित होता है: directory के लिए d, फिर owner के लिए rwx, फिर group के लिए r-x, और अन्य के लिए r-x।

कुछ systems ग्यारहवाँ अक्षर भी print करते हैं। एक trailing dot, drwxr-xr-x., का मतलब है कि file में एक SELinux (security enhanced Linux) context है, जिसे Fedora और Rocky जैसे SELinux distributions default रूप से print करते हैं। एक trailing plus, drwxr-xr-x+, का मतलब है कि file में एक POSIX ACL (access control list) है, जो इन नौ bits से परे नियमों का एक अतिरिक्त सेट है। उन अतिरिक्त नियमों को getfacl <path> के साथ पढ़ें।

directory पर r, w और x के कार्य अलग-अलग होते हैं

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

• फाइल पर r उसके कंटेंट को पढ़ता है। डायरेक्टरी पर r उसके अंदर मौजूद नामों की सूची दिखाता है, जो कि सामान्य ls के लिए आवश्यक है।
• फाइल पर w उसके कंटेंट को बदलता है। डायरेक्टरी पर w उसमें एंट्रीज को जोड़ता और हटाता है। किसी फाइल को डिलीट करना डायरेक्टरी में बदलाव है, इसलिए डायरेक्टरी पर राइट (write) अधिकार ही यह तय करता है, और फाइल का अपना मोड इसमें कोई भूमिका नहीं निभाता।
• फाइल पर x उसे प्रोग्राम के रूप में चलाता है। डायरेक्टरी पर x उसे ट्रैवर्स (traverse) करता है, जिसका अर्थ है कि कर्नल पाथ लुकअप के दौरान उसके अंदर के किसी नाम को रिजॉल्व कर सकता है।

ट्रैवर्स वह हिस्सा है जो लोगों को हैरान करता है। डायरेक्टरी पर x कुछ भी एक्जीक्यूट नहीं करता। /srv/site/index.html को खोलने के लिए / पर x, फिर /srv पर x, फिर /srv/site पर x, और अंत में फाइल पर r की आवश्यकता होती है। यदि उस चेन में किसी एक डायरेक्टरी में आपके लिए x की कमी है, तो लुकअप वहीं रुक जाता है, और कॉलर को पूरे पाथ के लिए Permission denied का एरर मिलता है, भले ही अंत में मौजूद फाइल सभी के पढ़ने के लिए उपलब्ध हो। namei -l /srv/site/index.html चेन के हर चरण को उसके मोड और ओनर के साथ प्रिंट करता है, ताकि आप देख सकें कि कौन सी कड़ी इसे रोक रही है।

r वाली लेकिन x रहित डायरेक्टरी एक अजीब आधी स्थिति है जिसे पहचानना जरूरी है। एक सामान्य यूजर नामों की सूची देख सकता है, क्योंकि लिस्टिंग r द्वारा मिलती है, लेकिन वह किसी भी एंट्री का stat नहीं ले सकता, इसलिए ls -l साइज और मोड कॉलम में प्रश्न चिह्न भर देता है और हर एक के लिए ls: cannot access ...: Permission denied प्रिंट करता है।

permissions को 755 में बदलना

प्रत्येक triad एक तीन-बिट संख्या है। r का मान 4 है, w का मान 2 है, और x का मान 1 है। जो बिट्स चालू (on) हैं, उन्हें जोड़ें।

• rwx का मान 4 + 2 + 1 = 7 है
• rw- का मान 4 + 2 = 6 है
• r-x का मान 4 + 1 = 5 है
• r-- का मान 4 है
• --- का मान 0 है

इसलिए drwxr-xr-x ओनर के लिए 7, ग्रुप के लिए 5 और अन्य के लिए 5 है: 755। -rw-r--r-- का मान 6, 4, 4 है: 644। drwxrwxr-x का मान 7, 7, 5 है: 775, जो कि 755 है जिसमें ग्रुप के लिए write अनुमति जोड़ी गई है। आपको कभी भी अक्षरों को हाथ से गिनने की आवश्यकता नहीं है, क्योंकि stat दोनों रूपों को एक साथ प्रिंट करता है।

stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt

%A अक्षर वाला रूप है, %a ऑक्टल रूप है, और %U तथा %G ओनर यूजर और ओनर ग्रुप के नाम दर्शाते हैं।

परमिशन स्ट्रिंग्स जिन्हें लोग अक्सर खोजते हैं

ये वे मोड्स हैं जो आपको एक वास्तविक सर्वर पर मिलते हैं, साथ ही इनका ऑक्टल मान और इनका उपयोग कहाँ होता है, यह भी दिया गया है।

• -rw-r--r-- का मान 644 है। सामान्य फाइलें जिन्हें कोई सर्विस केवल पढ़ती है, जैसे कि config फाइल या HTML पेज।
• -rw------- का मान 600 है। सीक्रेट्स: एक SSH private key, या किसी एप्लिकेशन की .env फाइल।
• -rw-rw-r-- का मान 664 है। एक ऐसी डायरेक्टरी में मौजूद फाइल जिसे एक ग्रुप साझा करता है, जहाँ टीम के सदस्यों को लिखने (write) की अनुमति चाहिए।
• -rwxr-xr-x का मान 755 है। स्क्रिप्ट्स और बाइनरीज, जैसे कि /usr/local/bin/backup.sh और अधिकांश /usr/bin।
• -rwx------ का मान 700 है। एक निजी स्क्रिप्ट जिसे केवल उसका मालिक ही चला सकता है।
• drwxr-xr-x का मान 755 है। लगभग हर सिस्टम डायरेक्टरी, और किसी वेबसाइट का डॉक्यूमेंट रूट।
• drwx------ का मान 700 है। ~/.ssh, और सुरक्षित किए गए सर्वर पर होम डायरेक्टरीज।
• drwxrwxr-x का मान 775 है। एक ऐसी डायरेक्टरी जिसमें मालिक का ग्रुप लिख सकता है।
• drwxrwsr-x का मान 2775 है। पिछला वाला ही, साथ में setgid बिट, ताकि अंदर बनने वाली नई फाइलें डायरेक्टरी का ग्रुप इनहेरिट कर लें।
• drwxrwxrwt का मान 1777 है। /tmp। अंत में लगा t स्टिकी बिट है, ताकि कोई यूजर केवल अपनी फाइलें ही डिलीट कर सके।
• -rwsr-xr-x का मान 4755 है। एक setuid बाइनरी जो अपने मालिक के रूप में चलती है, जैसे कि /usr/bin/passwd और /usr/bin/sudo।
• -rw-rw-rw- का मान 666 है, और drwxrwxrwx का मान 777 है। वर्ल्ड राइटेबल (कोई भी लिख सकता है), जो सर्वर पर लगभग हमेशा एक गलती होती है।
• lrwxrwxrwx वह है जो हर सिम्बॉलिक लिंक दिखाता है। Linux लिंक पर मौजूद मोड बिट्स को अनदेखा करता है और इसके बजाय टारगेट की जाँच करता है, इसलिए इस स्ट्रिंग का कोई अर्थ नहीं होता है।

कौन सा triad आप पर लागू होता है

यह दूसरा नियम है जिसे शुरुआती लोग गलत समझते हैं। kernel केवल एक triad चुनता है और वहीं रुक जाता है।

यदि आपका user ID फाइल के owner से मेल खाता है, तो आपको owner triad मिलता है, और group तथा other bits को कभी नहीं देखा जाता है। अन्यथा, यदि फाइल का group आपके groups में से एक है, तो आपको group triad मिलता है। अन्यथा आपको other triad मिलता है।

इससे दो बातें स्पष्ट होती हैं। owner triad तब भी लागू होता है जब वह सबसे अधिक restrictive हो। 0466 mode वाली एक फाइल, जो -r--rw-rw- के रूप में print होती है, अपने owner को केवल read की अनुमति देती है जबकि बाकी सभी write कर सकते हैं, क्योंकि owner check सबसे पहले मेल खा गया और उसके बाद कुछ भी नहीं पढ़ा गया। यह वैध है, और जो भी इसे पहली बार देखता है, वह भ्रमित हो जाता है।

इसके बाद group triad को फाइल के group द्वारा चुना जाता है, न कि उन groups की सूची द्वारा जिनसे आप संबंधित हैं। ls -l प्रत्येक line पर दो नाम print करता है: owner, फिर group। केवल वही दूसरा group उस फाइल पर कोई अधिकार रखता है। बीस groups का सदस्य होना केवल तभी मदद करता है जब फाइल उनमें से किसी एक को धारण करती हो।

id
stat -c '%U %G %A %n' ~/permdemo/inner/notes.txt

id आपके user और उन सभी groups को print करता है जिनमें आप शामिल हैं। stat फाइल के owner और group को print करता है। दोनों की तुलना करें और आपको पता चल जाएगा कि kernel आपके लिए किस triad का उपयोग करेगा।

यही कारण है कि एक shared directory को आमतौर पर एक group और setgid bit मिलता है। sudo chmod 2775 /srv/shared को drwxrwsr-x के रूप में print किया जाता है, और इसके अंदर बनाई गई फाइलें फिर creator के personal group के बजाय directory के group को inherit करती हैं, जबकि नई subdirectories को भी setgid bit मिल जाता है। Setgid group को set करता है, mode को नहीं। 022 के default umask के साथ, अंदर बनी एक नई फाइल अभी भी 644 के रूप में आती है, इसलिए टीम के सदस्य इसे read तो कर सकते हैं लेकिन write नहीं कर सकते। Group write के लिए वहाँ काम करने वाले प्रत्येक व्यक्ति के लिए 002 के umask की आवश्यकता होती है, या directory पर एक default ACL की, जो इसके अंदर बनाई गई फाइलों के लिए umask की जगह ले लेता है। प्रत्येक service को उसका अपना account देना इस कहानी का दूसरा हिस्सा है, और इसे VPS पर प्रति service एक Linux user में कवर किया गया है।

umask हर नई फ़ाइल का मोड निर्धारित करता है

एक नई फ़ाइल अपना मोड आपसे नहीं लेती है। यह उसे बनाने वाले प्रोग्राम से मिलता है, जिसमें से आपके umask द्वारा हटाए गए बिट्स घटा दिए जाते हैं। umask हटाने के लिए बिट्स का एक मास्क है, इसलिए बड़ा umask अधिक निजी फ़ाइलें बनाता है।

अधिकांश डिस्ट्रिब्यूशन 022 के साथ आते हैं। एक सामान्य फ़ाइल बनाने वाला प्रोग्राम आमतौर पर 0666 का अनुरोध करता है। एक डायरेक्टरी बनाने वाला प्रोग्राम आमतौर पर 0777 का अनुरोध करता है। umask दोनों अनुरोधों से 022 को हटा देता है, इसलिए आपको फ़ाइलों पर 644 और डायरेक्टरी पर 755 मिलता है। यह बिल्कुल वही जोड़ा है जो आप एक नए VPS पर हर जगह देखते हैं।

umask
umask -S
touch ~/permdemo/new.txt && mkdir -p ~/permdemo/newdir
ls -ld ~/permdemo/new.txt ~/permdemo/newdir

umask -S उसी मान को अक्षरों के रूप में प्रिंट करता है, जिसे 0022 की तुलना में पढ़ना आसान है। अधिक सख्त डिफ़ॉल्ट के लिए ~/.profile में umask 027 सेट करें: फ़ाइलों पर 640 और डायरेक्टरी पर 750, ताकि आपका ग्रुप आपके काम को पढ़ सके और कोई अन्य नहीं। ये परिणाम सामान्य 0666 और 0777 अनुरोधों को मानते हैं।

दो सीमाएं मायने रखती हैं। umask केवल बिट्स को हटा सकता है, उन्हें कभी जोड़ नहीं सकता। 0666 के रूप में अनुरोध की गई फ़ाइल, जो कि touch मांगता है, कभी भी निष्पादन योग्य (executable) नहीं होती है, चाहे आप कुछ भी सेट करें, और जो प्रोग्राम केवल ओनर एक्सेस मांगता है वह उसे बनाए रखता है: mktemp 022 या 027 के umask के तहत फ़ाइलों को 600 पर और डायरेक्टरी को 700 पर बनाता है। और एक systemd सर्विस कभी भी आपकी शेल प्रोफ़ाइल को नहीं पढ़ती है, इसलिए मान को यूनिट फ़ाइल में ही सेट करें।

[Service]
UMask=0027

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

वेब फाइलें 644 और वेब डायरेक्टरी 755 क्यों होती हैं

एक वेब सर्वर अपने स्वयं के अकाउंट के तहत चलता है, Debian और Ubuntu पर www-data, और Rocky तथा Alma पर nginx। उस प्रोसेस को उन फाइलों को पढ़ने की आवश्यकता होती है जिन्हें वह सर्व करता है और उनके ऊपर की डायरेक्टरीज़ को traverse करने की। उसे उन्हें लिखने (write) की कोई आवश्यकता नहीं है, और एक स्टेटिक साइट को इसकी अनुमति कभी नहीं देनी चाहिए।

फाइल पर 644 मोड ओनर को लिखने की अनुमति देता है और बाकी सभी को पढ़ने की, ताकि डिप्लॉय करने वाला यूजर पब्लिश कर सके और वेब यूजर सर्व कर सके। डायरेक्टरी पर 755 मोड ओनर को लिखने की अनुमति देता है और बाकी सभी को traverse करने की, ताकि वेब यूजर किसी भी चीज को जोड़े या हटाए बिना पाथ (path) से गुजर सके। इससे एप्लिकेशन में कोई बग होने पर भी वह उन पेजों को फिर से नहीं लिख सकता जिन्हें वह सर्व कर रहा है।

यहीं पर traverse नियम लागू होता है। यदि साइट /home/deploy/site में स्थित है, /home/deploy 750 है, और वेब यूजर डायरेक्टरी के ग्रुप में नहीं है, तो वेब यूजर होम डायरेक्टरी में प्रवेश ही नहीं कर पाएगा, और रिक्वेस्ट HTTP 403 के रूप में समाप्त होगी, जिसमें /var/log/nginx/error.log में इस तरह की एक लाइन होगी:

open() "/home/deploy/site/index.html" failed (13: Permission denied), client: 203.0.113.5

वह 13 EACCES है, जो कर्नल द्वारा अनुमति अस्वीकार (permission refusal) का संकेत है। नेटवर्क में कुछ भी गलत नहीं है: पोर्ट लिसनिंग मोड में है और रिक्वेस्ट पहुँच चुकी है, जो इसे तब भ्रमित करने वाला बनाता है जब आप अभी Linux पर लिसनिंग पोर्ट्स कैसे काम करते हैं सीख रहे होते हैं। namei -l /home/deploy/site/index.html चलाएं और उस पहली डायरेक्टरी के लिए चेन को नीचे पढ़ें जिसमें अन्य (other) के लिए x नहीं है।

एक डायरेक्टरी जिसमें एप्लिकेशन लिखता है, जैसे कि अपलोड पाथ, इसका अपवाद है। उसे व्यापक मोड देने के बजाय ओनरशिप के साथ अनुमति दें: sudo chown -R www-data:www-data /srv/site/uploads और मोड को 755 पर ही रहने दें। केवल उस एक डायरेक्टरी के लिए राइट एक्सेस रखें जिसे इसकी आवश्यकता है।

chmod, पूरे ट्री को प्रभावित किए बिना

chmod दोनों रूपों में काम करता है। Octal एक साथ सभी नौ bits को सेट करता है: chmod 644 notes.txt। Symbolic केवल उन्हीं को बदलता है जिन्हें आप निर्दिष्ट करते हैं और बाकी को वैसा ही रहने देता है: chmod u+x deploy.sh owner के लिए execute की अनुमति जोड़ता है, और chmod go-w notes.txt group और others से write की अनुमति हटा देता है।

Recursion वह स्थिति है जहाँ ट्री क्षतिग्रस्त हो सकते हैं। chmod -R 755 . हर image और हर config file को executable बना देता है, क्योंकि chmod किसी script और JPEG के बीच अंतर नहीं कर सकता। इसके बजाय capital X का उपयोग करें।

chmod -R u=rwX,go=rX ~/permdemo
stat -c '%a %n' ~/permdemo ~/permdemo/inner/notes.txt

Capital X केवल directories पर, और उन files पर execute की अनुमति लागू करता है जिनमें पहले से कहीं न कहीं execute bit मौजूद था। Directories 755 हो जाती हैं, सामान्य files 644 हो जाती हैं, और जो scripts पहले से executable थीं, वे वैसी ही बनी रहती हैं। जब किसी एक file का mode आपके भरोसेमंद हो, तो chmod --reference=good.sh other.sh उसे अन्य पर कॉपी कर देता है।

जब बिट गलत हो तो दिखने वाले संदेश

bash: ./deploy.sh: Permission denied का अर्थ है कि script में आपके लिए लागू triad में x बिट नहीं है, या इसके path पर स्थित किसी directory में x नहीं है। chmod u+x deploy.sh पहले मामले को ठीक कर देता है।

bash: ./deploy.sh: cannot execute: required file not found एक अलग त्रुटि है जिसका नाम भ्रमित करने वाला है। x बिट ठीक है, लेकिन पहली पंक्ति में नामित interpreter मौजूद नहीं है। इसका सामान्य कारण Windows line endings हैं, इसलिए kernel /bin/bash\r नामक interpreter की तलाश कर रहा है। इसे sed -i 's/\r$//' deploy.sh से ठीक करें।

Permissions 0644 for '/home/deploy/.ssh/id_ed25519' are too open. SSH client से आता है, जो ऐसी private key का उपयोग करने से मना कर देता है जिसे अन्य accounts पढ़ सकते हैं। Key के लिए 600 और ~/.ssh के लिए 700 की अनुमति आवश्यक है। Key हैंडलिंग की पूरी जानकारी SSH keys और उनकी file permissions को मैनेज करना में दी गई है।

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh सर्वर के journal में तब दिखाई देता है जब home directory या उसकी .ssh group writable होती है। sshd की StrictModes सेटिंग key को अस्वीकार कर देती है, और client side से यह बिना किसी स्पष्टीकरण के एक अप्रत्याशित password prompt जैसा दिखता है।

sudo: /etc/sudoers is world writable, जिसके बाद sudo: no valid sudoers sources found, quitting आता है, का अर्थ है कि sudo ने अपनी config के mode की जाँच की और चलने से मना कर दिया। उस file का mode 0440 होना चाहिए और वह कभी भी world writable नहीं होनी चाहिए। यह एक व्यापक recursive chmod का क्लासिक परिणाम है, और यह ऊपर दिए गए sshd संदेश के साथ आ सकता है, जिससे सिस्टम में वापस आने का एकमात्र तरीका provider का console ही बचता है।

777 एक समाधान क्यों नहीं है

777 मशीन पर मौजूद हर account और उन accounts के तहत चलने वाली हर process को write access देता है। एक सर्वर अपनी services को उनके अपने users के तहत चलाता है, इसलिए VPS पर "हर कोई" (everyone) का दायरा लैपटॉप की तुलना में कहीं अधिक बड़ा होता है। यदि कोई service breach हो जाती है, तो वह उन सभी जगहों पर लिख सकती है जहाँ 777 की अनुमति है।

Web root के अंतर्गत इसका नुकसान सीधा होता है। यदि कोई directory world-writable है और सर्वर उसे serve भी कर रहा है, तो file upload की एक खामी का उपयोग करके कोई script plant की जा सकती है और फिर उसे request किया जा सकता है।

Ownership से जुड़ी समस्या का समाधान लगभग कभी भी 777 नहीं होता है। समस्या का लक्षण यह होता है कि "app इस directory में लिख नहीं पा रही है"। इसका वास्तविक कारण यह है कि directory गलत user के स्वामित्व में है। sudo chown -R appuser:appuser /srv/app/storage के साथ 755 mode का उपयोग करने से यह समस्या हल हो जाती है: application वहाँ लिख सकती है, और बाकी सभी accounts directory को देख और उसमें प्रवेश तो कर सकते हैं, लेकिन उसमें कुछ लिख नहीं सकते। किसी भी चीज़ को deploy करने से पहले उन accounts को बनाना एक नए VPS पर शुरुआती दस मिनट का हिस्सा है।

World-write की अनुमति केवल एक परिचित स्थान पर वैध है, /tmp, और इसे drwxrwxrwt लिखा जाता है। अंत में लगा t sticky bit है: directory सभी के लिए writable है, फिर भी एक user केवल उन्हीं files को delete कर सकता है जिनका वह स्वामी है। इस bit के बिना, कोई भी account किसी दूसरे account की temporary files को delete कर सकता है।

बदलाव करने से पहले मोड को पढ़ें

ये commands केवल state को पढ़ती हैं, इसलिए इन्हें कहीं भी चलाना सुरक्षित है।

id
umask
stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt
namei -l ~/permdemo/inner/notes.txt
find ~/permdemo -perm -0002

find <path> -perm -0002 उस path के अंतर्गत आने वाली हर चीज़ को list करता है जिसका world write bit set है। जब कोई व्यक्ति chmod 777 का उपयोग करके चीजों को ठीक कर रहा हो, तो उसके बाद किसी box का audit करने का यह सबसे तेज़ तरीका है।

यह जानने के लिए कि क्या कोई विशिष्ट service account किसी directory में प्रवेश कर सकता है, उसी account के रूप में पूछें। यदि उस user के पास directory पर traverse की अनुमति है, तो sudo -u www-data test -x /srv/site && echo yes || echo no, yes print करता है, और यदि नहीं है, तो no print करता है। root के रूप में पूछने से कुछ भी सिद्ध नहीं होता, क्योंकि root इस जाँच को छोड़ देता है और उत्तर हमेशा yes ही होता है।

FAQ

Linux में drwxr-xr-x का क्या अर्थ है?

यह एक directory है, जिसे शुरुआती d द्वारा दर्शाया गया है, और इसका mode 755 है। owner triad rwx है, इसलिए owner के पास इस पर सभी अनुमतियाँ हैं। group triad r-x है और other triad r-x है, इसलिए बाकी सभी लोग इसके अंदर की फाइलों की सूची देख सकते हैं और directory के माध्यम से जा सकते हैं, जबकि owner के अलावा कोई भी इसमें कुछ जोड़ या हटा नहीं सकता है। किसी भी path की पुष्टि stat -c '%A %a %U %G %n' <path> के साथ करें, जो letter form और octal form को एक साथ दिखाता है।

वेब फाइलें 644 और वेब डायरेक्टरी 755 क्यों होती हैं?

वेब सर्वर एक अलग account के तहत चलता है, जो Ubuntu पर www-data है। इसे उन फाइलों को पढ़ने की आवश्यकता होती है जिन्हें यह serve करता है और उनके ऊपर की हर directory को traverse करने की आवश्यकता होती है, और इसे किसी भी फाइल या directory में लिखने का कोई कारण नहीं है। 644 owner को write access देता है और बाकी सभी को read access। 755 owner को write access देता है और बाकी सभी को traverse access। जिस directory में application को वास्तव में लिखने की आवश्यकता हो, उसे chown के साथ उस application के user को सौंप दिया जाना चाहिए, न कि सभी के लिए mode को ढीला करके।

क्या x bit का मतलब है कि मैं एक directory को execute कर सकता हूँ?

नहीं। एक directory पर x का अर्थ traverse है, जो कि kernel द्वारा path को walk करते समय उसके अंदर के नाम को resolve करने का अधिकार है। cd को इसकी आवश्यकता होती है, और इसके नीचे की किसी भी फाइल को open करने के लिए भी इसकी आवश्यकता होती है। path में मौजूद प्रत्येक directory को x की आवश्यकता होती है, इसलिए mode 644 वाली फाइल भी तब तक पहुंच योग्य नहीं होती जब तक कि उसके ऊपर की directory में आपके लिए x न हो। namei -l /path/to/file chain में मौजूद प्रत्येक directory का mode print करता है, जो यह दिखाता है कि lookup कहाँ रुकता है।

क्या chmod 777 कभी सही समाधान होता है?

सर्वर पर लगभग कभी नहीं। यह मशीन पर मौजूद हर account को write access देता है, जिसमें वे accounts भी शामिल हैं जिनके तहत services चलती हैं, इसलिए एक compromised service फाइल को rewrite कर सकती है। जब कोई application किसी directory में लिख नहीं पाता है, तो वास्तविक समस्या आमतौर पर ownership की होती है: mode 755 के साथ sudo chown -R appuser:appuser /srv/app/storage application को write access देता है, जबकि अन्य accounts directory को पढ़ तो सकते हैं लेकिन उसमें लिख नहीं सकते। इसका परिचित अपवाद 1777 पर /tmp है, और यह केवल इसलिए काम करता है क्योंकि sticky bit users को एक-दूसरे की फाइलें delete करने से रोकता है।

ls अनुमतियों के बाद dot या plus क्यों print करता है?

वह ग्यारहवाँ character नौ permission bits से परे के नियमों का वर्णन करता है। एक dot, जैसा कि drwxr-xr-x. में है, का अर्थ है कि एक SELinux security context संलग्न है, जो Fedora और Rocky पर सामान्य है। एक plus, जैसा कि drwxr-xr-x+ में है, का अर्थ है कि एक POSIX ACL (access control list) set है, इसलिए कुछ user या group के पास ऐसे अधिकार हैं जो तीन triads में नहीं दिखते। उन अतिरिक्त entries को list करने के लिए getfacl <path> चलाएँ।