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

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

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

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

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

एक 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 बिट्स को कभी नहीं देखा जाता। अन्यथा, यदि फाइल का group आपके groups में से एक है, तो आपको group triad मिलता है। अन्यथा आपको other triad मिलता है।

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

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

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

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

यही कारण है कि एक shared directory को आमतौर पर एक group और setgid बिट मिलता है। sudo chmod 2775 /srv/shared को drwxrwsr-x के रूप में प्रिंट किया जाता है, और इसके अंदर बनाई गई फाइलें निर्माता के व्यक्तिगत group के बजाय directory के group को inherit करती हैं, ताकि अगला व्यक्ति अभी भी उन्हें लिख सके। प्रत्येक service को अपना स्वयं का account देना इस कहानी का दूसरा आधा हिस्सा है, और इसे VPS पर प्रति service एक Linux user में कवर किया गया है।

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

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

अधिकांश distributions 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, ताकि आपका ग्रुप आपके काम को पढ़ सके और कोई अन्य नहीं।

दो सीमाएं मायने रखती हैं। umask केवल बिट्स को हटा सकता है, उन्हें कभी जोड़ नहीं सकता, यही कारण है कि एक नई बनाई गई फाइल कभी भी निष्पादन योग्य (executable) नहीं होती है, चाहे आप कुछ भी सेट करें। और एक systemd service कभी भी आपकी shell profile को नहीं पढ़ती है, इसलिए मान को unit file में ही सेट करें।

[Service]
UMask=0027

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

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

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

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 है, जो कर्नल का परमिशन रिफ्यूजल है। नेटवर्क में कुछ भी गलत नहीं है: पोर्ट लिसन कर रहा है और रिक्वेस्ट आ गई है, जो इसे तब भ्रमित करने वाला बनाता है जब आप अभी Linux पर लिसनिंग पोर्ट्स कैसे काम करते हैं सीख रहे होते हैं। namei -l /home/deploy/site/index.html चलाएं और अन्य के लिए 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 अनुमति (permission) आवश्यक है। 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 होना चाहिए। यह व्यापक recursive chmod का क्लासिक परिणाम है, और यह ऊपर दिए गए sshd संदेश के साथ भी आ सकता है, जिससे वापस अंदर जाने का एकमात्र तरीका provider का console ही बचता है।

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

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

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

ownership से जुड़ी समस्या के लिए 777 लगभग हमेशा गलत उत्तर होता है। इसका लक्षण यह है कि "app इस directory में write नहीं कर पा रही है"। इसका कारण यह है कि directory गलत user की है। sudo chown -R appuser:appuser /srv/app/storage के साथ mode 755 का उपयोग इसे हल करता है और अन्य सभी accounts को बाहर रखता है। कुछ भी 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 के पास इस पर सभी permissions हैं। 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 को वास्तव में लिखने की आवश्यकता हो, उसे सभी के लिए mode को व्यापक बनाने के बजाय chown के साथ उस application के user को सौंप दिया जाना चाहिए।

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

नहीं। एक directory पर x का अर्थ traverse है, जो कि path को resolve करने का अधिकार है जब kernel किसी path पर चलता है। cd को इसकी आवश्यकता होती है, और इसके नीचे किसी भी फाइल को open करने के लिए भी इसकी आवश्यकता होती है। path में प्रत्येक directory को x की आवश्यकता होती है, इसलिए mode 644 वाली फाइल भी तब तक unreachable रहती है जब तक कि उसके ऊपर की 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 को वह सब कुछ देता है जिसकी उसे आवश्यकता है और बाकी सभी को बाहर रखता है। इसका एक जाना-माना अपवाद 1777 पर /tmp है, और यह केवल इसलिए काम करता है क्योंकि sticky bit users को एक-दूसरे की फाइलें delete करने से रोकता है।

ls permissions के बाद dot या plus क्यों print करता है?

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