drwxr-xr-x म्हणजे काय? Linux permissions आणि 755
drwxr-xr-x मधील प्रत्येक अक्षर समजून 755 mode ओळखा. Directory वरील x म्हणजे traverse, आणि chmod 777 हा योग्य उपाय का नाही ते जाणून घ्या.
drwxr-xr-x म्हणजे काय
drwxr-xr-x हा असा directory दर्शवतो की त्याचा owner त्यात बदल करू शकतो आणि इतर प्रत्येक user तो वाचू शकतो व त्यामधून पुढे जाऊ शकतो, परंतु त्यात कोणताही बदल करू शकत नाही. Octal मध्ये हा mode 755 असतो. Linux प्रत्येक ls -l output मधील प्रत्येक ओळीच्या सुरुवातीला ही दहा characters छापतो. त्या नेहमी त्याच क्रमाने तोच अर्थ दर्शवतात. त्यामुळे एक string समजून घेतल्यास हे सर्व समजते.
पुढील नियम आधी समजून घेणे आवश्यक आहे, कारण तुमच्या स्वतःच्या testing मधून काही निष्कर्ष निघतील की नाही हे त्यावर ठरते. root user permission bits कडे दुर्लक्ष करतो. Kernel root ला CAP_DAC_OVERRIDE capability (discretionary access control override) देते. त्यामुळे mode मध्ये परवानगी नसली तरी root files उघडू शकतो. या page वरील प्रत्येक example root साठी bits काहीही दर्शवत असले तरी यशस्वी होतो. नियम प्रत्यक्ष लागू होताना पाहायचे असल्यास normal user म्हणून login करा.
दहा अक्षरे, एकावेळी एक
पाहणी करण्यासाठी एक directory आणि एक file तयार करा. येथे नवीन directory च्या बाहेर कोणत्याही गोष्टीवर परिणाम होत नाही.
mkdir -p ~/permdemo/inner
printf 'hello\n' > ~/permdemo/inner/notes.txt
ls -ld ~/permdemo ~/permdemo/inner ~/permdemo/inner/notes.txt022 या सर्वसाधारण default umask मुळे, directory च्या दोन ओळी drwxr-xr-x ने सुरू होतात आणि file ची ओळ -rw-r--r-- ने सुरू होते.
पहिले अक्षर file type दर्शवते; ते permission नाही. d म्हणजे directory. - म्हणजे regular file. l म्हणजे symbolic link. c आणि b म्हणजे character आणि block device nodes. s म्हणजे socket, तर p म्हणजे named pipe. हे octal value च्या बाहेर असते. म्हणून drwxr-xr-x हे 755 होते; ते d ने सुरू होत नाही.
त्यानंतरची नऊ अक्षरे प्रत्येकी तीन अक्षरांच्या तीन गटांत असतात. त्यांचा क्रम कधीही बदलत नाही.
- 2 ते 4 ही अक्षरे मालकाची triad असतात. ती file च्या मालकाच्या user ला लागू होणारे bits दर्शवतात.
- 5 ते 7 ही अक्षरे group triad असतात. ती file च्या group ला लागू होणारे bits दर्शवतात.
- 8 ते 10 ही अक्षरे इतरांची triad असतात. ती इतर सर्वांना लागू होणारे bits दर्शवतात.
प्रत्येक triad मध्ये slots नेहमी r, त्यानंतर w आणि त्यानंतर x या क्रमाने असतात. dash म्हणजे तो bit बंद आहे. अक्षरांची जागा कधीही बदलत नाही. r-x म्हणजे write शिवाय read. -w- म्हणजे read शिवाय write; हे वैध आहे, परंतु क्वचित आढळते.
म्हणून drwxr-xr-x चे विभाजन असे होते: directory साठी d, त्यानंतर मालकासाठी rwx, group साठी r-x आणि इतरांसाठी r-x.
काही systems अकरावे अक्षर दाखवतात. शेवटी असलेला dot, drwxr-xr-x., म्हणजे file सोबत SELinux (security enhanced Linux) context जोडलेला आहे. Fedora आणि Rocky सारख्या SELinux distributions मध्ये तो default ने दाखवला जातो. शेवटी असलेला plus, drwxr-xr-x+, म्हणजे file सोबत POSIX ACL (access control list) जोडलेली आहे. या नऊ bits व्यतिरिक्त ती नियमांचा एक अतिरिक्त संच असतो. हे अतिरिक्त नियम getfacl <path> ने वाचा.
निर्देशिकेवर r, w आणि x वेगवेगळी कामे करतात
नवशिके सर्वात जास्त चूक या पहिल्या नियमात करतात. फाइल आणि निर्देशिका यांच्यावर ही अक्षरे समान असतात. मात्र त्यांच्यामुळे मिळणारे अधिकार समान नसतात.
- फाइलवरील
rतिचा मजकूर वाचते. निर्देशिकेवरीलrतिच्यातील नावे दाखवते. साध्याlsसाठी हे आवश्यक असते. - फाइलवरील
wतिचा मजकूर बदलते. निर्देशिकेवरीलwतिच्यातील नोंदी जोडते आणि काढते. फाइल हटवणे म्हणजे निर्देशिकेत बदल करणे. त्यामुळे त्यासाठी निर्देशिकेवरील write permission निर्णायक असते; फाइलच्या स्वतःच्या mode चा त्यावर परिणाम होत नाही. - फाइलवरील
xतिला program म्हणून चालवते. निर्देशिकेवरीलxतिच्यातून traverse करण्याची परवानगी देते. म्हणजे path lookup दरम्यान kernel तिच्यातील एखादे नाव resolve करू शकतो.
Traverse हा भाग अनेकांना आश्चर्यचकित करतो. निर्देशिकेवरील x काहीही execute करत नाही. /srv/site/index.html उघडण्यासाठी / वर x, त्यानंतर /srv वर x, पुढे /srv/site वर x आणि शेवटी फाइलवर r आवश्यक असते. या साखळीतील एखाद्या निर्देशिकेवर तुमच्यासाठी x नसेल, तर lookup तिथेच थांबतो. फाइल शेवटी world-readable असली तरी संपूर्ण path साठी caller ला Permission denied मिळते. namei -l /srv/site/index.html या साखळीतील प्रत्येक टप्पा त्याचा mode आणि मालकासह दाखवते. त्यामुळे कोणता दुवा lookup थांबवतो हे पाहता येते.
r असून x नसलेली निर्देशिका ही ओळखण्यासारखी विचित्र अर्धवट अवस्था आहे. सामान्य user नावे पाहू शकतो, कारण listing ची परवानगी r देते. मात्र तो कोणत्याही entry वर stat करू शकत नाही. त्यामुळे ls -l size आणि mode चे columns question marks ने भरते आणि प्रत्येक entry साठी ls: cannot access ...: Permission denied दाखवते.
अक्षरांना 755 मध्ये रूपांतरित करणे
प्रत्येक त्रिकूट ही तीन बिटची संख्या असते. r चे मूल्य 4, w चे मूल्य 2 आणि x चे मूल्य 1 असते. सक्रिय असलेल्या बिटची मूल्ये एकत्र करा.
rwx= 4 + 2 + 1 = 7rw-= 4 + 2 = 6r-x= 4 + 1 = 5r--= 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 हे octal स्वरूप, तर %U आणि %G हे मालकाचा user आणि मालकाचा group दर्शवतात.
लोक जे permission strings शोधतात
खऱ्या सर्व्हरवर आढळणारे हे modes आहेत. त्यांच्यासोबत octal value आणि प्रत्येक mode कुठे वापरला जातो ते दिले आहे.
-rw-r--r--हे 644 आहे. Service फक्त वाचत असलेल्या सामान्य files, जसे की config file किंवा HTML page.-rw-------हे 600 आहे. Secrets: SSH private key किंवा application ची.envfile.-rw-rw-r--हे 664 आहे. Group ने share केलेल्या directory मधील file, ज्यात team members ना write करण्याची आवश्यकता असते.-rwxr-xr-xहे 755 आहे. Scripts आणि binaries, जसे की/usr/local/bin/backup.shआणि बहुतेक/usr/bin.-rwx------हे 700 आहे. फक्त owner चालवू शकेल अशी private script.drwxr-xr-xहे 755 आहे. जवळजवळ प्रत्येक system directory आणि website चा document root.drwx------हे 700 आहे.~/.sshआणि locked-down box वरील home directories.drwxrwxr-xहे 775 आहे. Owner चा group ज्यात write करू शकतो अशी directory.drwxrwsr-xहे 2775 आहे. याच्यासोबत setgid bit असतो. त्यामुळे त्यामध्ये तयार होणाऱ्या नवीन files ना directory चा group वारशाने मिळतो.drwxrwxrwtहे 1777 आहे./tmp. शेवटचाtहा sticky bit असतो. त्यामुळे user फक्त स्वतःच्या files delete करू शकतो.-rwsr-xr-xहे 4755 आहे. Owner म्हणून चालणारा setuid binary, जसे की/usr/bin/passwdआणि/usr/bin/sudo.-rw-rw-rw-हे 666 आणिdrwxrwxrwxहे 777 आहे. World-writable permissions सर्व्हरवर जवळजवळ नेहमीच चुकीच्या असतात.- Symbolic link दाखवणारा mode
lrwxrwxrwxअसतो. Linux link वरील mode bits दुर्लक्षित करून target तपासते. त्यामुळे या string ला कोणताही अर्थ नसतो.
तुमच्यासाठी कोणता triad लागू होतो
ही beginners कडून होणारी दुसरी सामान्य चूक आहे. kernel नेमका एकच triad निवडतो आणि त्यानंतर थांबतो.
तुमचा user ID file च्या owner शी जुळत असेल, तर तुम्हाला owner triad लागू होतो. group आणि other bits तपासले जात नाहीत. तसे नसल्यास, file चा group तुमच्या groups पैकी एक असेल, तर तुम्हाला group triad लागू होतो. अन्यथा other triad लागू होतो.
यातून दोन गोष्टी स्पष्ट होतात. owner triad सर्वात restrictive असला तरी तोच लागू होतो. 0466 mode असलेली file, जी -r--rw-rw- म्हणून दिसते, तिच्या owner ला फक्त read अधिकार देते आणि इतर सर्वांना write करता येते. कारण owner check आधी जुळला आणि त्यानंतरचे कोणतेही bits वाचले गेले नाहीत. हे वैध आहे आणि पहिल्यांदा पाहताना सर्वांना गोंधळात टाकते.
group triad तुम्ही ज्या groups मध्ये आहात त्यांच्या यादीवर नव्हे, तर file च्या group वरून निवडला जातो. ls -l प्रत्येक line वर दोन names दाखवते: आधी owner, त्यानंतर group. त्या file साठी अधिकार ठरवताना फक्त दुसऱ्या group चा विचार केला जातो. तुम्ही वीस groups मध्ये असलात तरी file त्यापैकी एखादा group वापरत असेल तेव्हाच त्याचा उपयोग होतो.
id
stat -c '%U %G %A %n' ~/permdemo/inner/notes.txtid तुमचा user आणि तुम्ही ज्या प्रत्येक group मध्ये आहात ते दाखवते. stat file चा owner आणि group दाखवते. दोन्हींची तुलना केल्यावर kernel तुमच्यासाठी कोणता triad वापरेल हे समजते.
म्हणून shared directory ला सामान्यतः group आणि setgid bit दिला जातो. sudo chmod 2775 /srv/shared हे drwxrwsr-x म्हणून दिसते. त्यानंतर त्या directory मध्ये तयार होणाऱ्या files ला creator च्या personal group ऐवजी directory चा group inherit होतो. त्यामुळे पुढील user त्यांमध्ये write करू शकतो. प्रत्येक service साठी स्वतंत्र account देणे हा या रचनेचा दुसरा भाग आहे. याचे वर्णन VPS वर प्रत्येक service साठी एक Linux user येथे केले आहे.
umask प्रत्येक नवीन फाइलचा mode ठरवतो
नवीन फाइलचा mode तुमच्याकडून घेतला जात नाही. तो फाइल तयार करणाऱ्या program कडून घेतला जातो आणि तुमचा umask जे bits clear करतो ते वजा केले जातात. umask हा काढून टाकायच्या bits चा mask आहे. त्यामुळे umask मोठा असेल तर फाइल्स अधिक private असतात.
बहुतेक distributions मध्ये 022 असतो. Regular file तयार करणारा program 0666 मागतो. Directory तयार करणारा program 0777 मागतो. umask दोन्ही requests मधून 022 clear करतो. त्यामुळे files साठी 644 आणि directories साठी 755 मिळतात. Fresh VPS वर सर्वत्र दिसणारी हीच जोडी आहे.
umask
umask -S
touch ~/permdemo/new.txt && mkdir -p ~/permdemo/newdir
ls -ld ~/permdemo/new.txt ~/permdemo/newdirumask -S हीच value letters मध्ये print करतो. 0022 पेक्षा ती वाचणे सोपे असते. अधिक strict default साठी ~/.profile मध्ये umask 027 सेट करा: files साठी 640 आणि directories साठी 750. त्यामुळे तुमचा group तुमचे work read करू शकतो आणि इतर कोणालाही ते करता येत नाही.
दोन मर्यादा महत्त्वाच्या आहेत. umask फक्त bits clear करू शकतो; ते कधीही add करू शकत नाही. त्यामुळे तुम्ही कोणतीही value set केली तरी नव्याने तयार झालेली file executable कधीही नसते. तसेच systemd service तुमचा shell profile कधीही read करत नाही. त्यामुळे ही value unit file मध्येच सेट करा.
[Service]
UMask=0027वेब फाइल्स 644 आणि वेब डिरेक्टरीज 755 का असतात
वेब सर्व्हर स्वतःच्या account अंतर्गत चालतो: Debian आणि Ubuntu वर www-data, तर Rocky आणि Alma वर nginx. या process ला तो उपलब्ध करून देत असलेल्या फाइल्ससाठी read आणि त्या फाइल्सपर्यंतच्या वरील directories साठी traverse परवानगी आवश्यक असते. त्या फाइल्समध्ये write करण्याचे त्याला कोणतेही कारण नसते. Static site ने ही परवानगी कधीही देऊ नये.
फाइलवर 644 असल्यास owner ला write आणि सर्वांना read परवानगी मिळते. त्यामुळे deploy user फाइल्स publish करू शकतो आणि web user त्या उपलब्ध करून देऊ शकतो. Directory वर 755 असल्यास owner ला write आणि सर्वांना traverse परवानगी मिळते. त्यामुळे web user path मधून पुढे जाऊ शकतो, पण काहीही add किंवा delete करू शकत नाही. त्यामुळे application मधील bug मुळे ती application स्वतः उपलब्ध करून देत असलेली pages पुन्हा लिहू शकत नाही.
Traverse नियम येथे महत्त्वाचा ठरतो. Site /home/deploy/site मध्ये असल्यास आणि /home/deploy ची permission 750 असल्यास, web user home directory मध्ये प्रवेश करू शकत नाही. त्यामुळे request HTTP 403 सह समाप्त होते आणि /var/log/nginx/error.log मध्ये यासारखी ओळ दिसते:
open() "/home/deploy/site/index.html" failed (13: Permission denied), client: 203.0.113.5तो 13 म्हणजे EACCES, म्हणजे kernel ने परवानगी नाकारली आहे. Network मध्ये काहीही दोष नसतो: port listening स्थितीत असतो आणि request पोहोचलेली असते. Linux वर listening ports कसे कार्य करतात हे शिकत असताना हा मुद्दा गोंधळात टाकतो. Linux वर listening ports कसे कार्य करतात namei -l /home/deploy/site/index.html चालवा आणि chain मध्ये खाली जाऊन इतरांसाठी x नसलेली पहिली directory शोधा.
Application ज्या directory मध्ये write करते, जसे upload path, ती अपवादात्मक स्थिती आहे. अधिक व्यापक mode देण्याऐवजी ownership वापरून त्या directory ला परवानगी द्या: sudo chown -R www-data:www-data /srv/site/uploads आणि mode 755 ठेवा. Write access फक्त आवश्यक असलेल्या त्या एकाच directory पुरता मर्यादित ठेवा.
chmod, संपूर्ण directory tree flatten न करता
chmod हे दोन्ही प्रकार स्वीकारते. Octal पद्धतीने सर्व नऊ bits एकाच वेळी सेट होतात: chmod 644 notes.txt. Symbolic पद्धतीत तुम्ही निर्दिष्ट केलेलाच बदल होतो आणि उर्वरित mode तसाच राहतो: chmod u+x deploy.sh मालकासाठी execute bit जोडते, तर chmod go-w notes.txt group आणि other साठी write bit काढून टाकते.
Recursion मुळे directory tree खराब होऊ शकते. chmod -R 755 . प्रत्येक image आणि प्रत्येक configuration file executable करते, कारण chmod script आणि JPEG यांमध्ये फरक ओळखू शकत नाही. त्याऐवजी capital X वापरा.
chmod -R u=rwX,go=rX ~/permdemo
stat -c '%a %n' ~/permdemo ~/permdemo/inner/notes.txtCapital X directories आणि आधीच कुठेतरी execute bit असलेल्या files वर execute लागू करते. Directories चा mode 755 होतो, सामान्य files चा mode 644 होतो आणि आधीपासून executable असलेले scripts तसेच राहतात. एखाद्या file चा mode योग्य असल्याची खात्री असल्यास chmod --reference=good.sh other.sh तो mode इतर files वर लागू करते.
चुकीचा bit असल्यावर दिसणारे संदेश
bash: ./deploy.sh: Permission denied याचा अर्थ, तुमच्यावर लागू होणाऱ्या triad मध्ये script कडे x bit नाही किंवा तिच्या path मधील एखाद्या directory कडे x नाही. पहिली स्थिती chmod u+x deploy.sh दुरुस्त करते.
bash: ./deploy.sh: cannot execute: required file not found ही वेगळ्या प्रकारची आणि गोंधळात टाकणाऱ्या नावाची त्रुटी आहे. x bit योग्य आहे, पण पहिल्या ओळीवर नमूद केलेला 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 कडून येतो. इतर accounts वाचू शकतील अशी private key वापरण्यास तो नकार देतो. Key साठी 600 आणि ~/.ssh साठी 700 असणे आवश्यक आहे. Key हाताळणीची संपूर्ण माहिती SSH keys आणि त्यांच्या file permissions चे व्यवस्थापन येथे आहे.
Authentication refused: bad ownership or modes for directory /home/deploy/.ssh हा संदेश server च्या journal मध्ये दिसतो, जेव्हा home directory किंवा तिचे .ssh group writable असते. sshd मधील StrictModes setting ही key नाकारते. Client कडून पाहता, यामुळे कोणतेही स्पष्टीकरण न देता अनपेक्षित 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 ला आणि त्या account अंतर्गत चालणाऱ्या प्रत्येक process ला write access मिळतो. Server वर services त्यांच्या स्वतंत्र users अंतर्गत चालतात. त्यामुळे VPS वर “everyone” मध्ये laptop पेक्षा बरेच अधिक घटक येतात. Compromise झालेली service 777 मुळे परवानगी असलेल्या कोणत्याही ठिकाणी लिहू शकते.
Web root अंतर्गत यामुळे थेट नुकसान होऊ शकते. Server ज्या world-writable directory मधील files serve करतो, तिथे file upload मधील flaw वापरून script ठेवता येतो आणि नंतर त्याची request करता येते.
Ownership संबंधीच्या प्रश्नासाठी 777 हे जवळजवळ नेहमीच चुकीचे उत्तर असते. लक्षण असे असते: “app या directory मध्ये लिहू शकत नाही.” कारण म्हणजे directory चुकीच्या user च्या मालकीची असते. sudo chown -R appuser:appuser /srv/app/storage mode 755 सह ते दुरुस्त करते आणि इतर सर्व accounts ला बाहेर ठेवते. कोणतीही deployment करण्यापूर्वी ही accounts तयार करणे नवीन VPS वरील पहिल्या दहा मिनिटांचा भाग आहे.
World write एका परिचित ठिकाणी योग्य आहे: /tmp, आणि त्याची रचना drwxrwxrwt अशी आहे. शेवटचा t हा sticky bit आहे: directory सर्वांसाठी writable असते, तरी user फक्त स्वतःच्या मालकीच्या files delete करू शकतो. हा bit नसल्यास कोणतेही account दुसऱ्या account च्या temporary files delete करू शकते.
बदलण्यापूर्वी mode वाचा
हे commands फक्त सद्यस्थिती वाचतात, त्यामुळे ते कुठेही चालवणे सुरक्षित आहे.
id
umask
stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt
namei -l ~/permdemo/inner/notes.txt
find ~/permdemo -perm -0002find <path> -perm -0002 अशा path अंतर्गत world write bit सेट असलेल्या सर्व गोष्टींची यादी करते. chmod 777 वापरून कोणी दुरुस्ती केल्यानंतर एखाद्या server चे audit करण्याचा हा सर्वात जलद मार्ग आहे.
एखाद्या विशिष्ट service account ला directory मध्ये प्रवेश करता येतो का हे तपासण्यासाठी, त्या account म्हणून तपासा. त्या user कडे directory वर traverse permission असल्यास sudo -u www-data test -x /srv/site && echo yes || echo no yes दाखवते आणि नसल्यास no दाखवते. root म्हणून तपासल्याने काहीही सिद्ध होत नाही, कारण root ही तपासणी वगळतो आणि उत्तर नेहमी yes असते.
FAQ
Linux मध्ये drwxr-xr-x म्हणजे काय?
सुरुवातीचा d दर्शवतो की ही directory आहे आणि तिचा mode 755 आहे. मालकाचा triad rwx आहे, त्यामुळे मालकाला तिच्यावरील सर्व permissions आहेत. group triad r-x आणि other triad r-x आहेत. त्यामुळे इतर सर्वांना आतील नावे सूचीबद्ध करता येतात आणि directory मधून पुढे जाता येते; मात्र मालकाशिवाय इतर कोणालाही काहीही जोडता किंवा काढता येत नाही. कोणताही path stat -c '%A %a %U %G %n' <path> ने पडताळा. हा command अक्षरी आणि octal स्वरूप शेजारीशेजारी दाखवतो.
web files 644 आणि web directories 755 का असतात?
web server वेगळ्या account अंतर्गत चालतो. Ubuntu वर हे account www-data आहे. त्याने पुरवलेल्या files वाचता आल्या पाहिजेत आणि त्या files पर्यंतच्या प्रत्येक वरील directory मधून traverse करता आले पाहिजे. त्याला यापैकी कोणत्याही ठिकाणी write करण्याची आवश्यकता नसते. 644 मुळे मालकाला write आणि इतर सर्वांना read मिळतो. 755 मुळे मालकाला write आणि इतर सर्वांना traverse मिळतो. ज्या directory मध्ये application ला प्रत्यक्ष write करणे आवश्यक आहे, ती directory chown ने त्या application च्या user कडे सोपवा. सर्वांसाठी mode अधिक सैल करू नका.
x bit म्हणजे directory execute करता येते का?
नाही. Directory वर x म्हणजे traverse. Kernel path वरून पुढे जाताना तिच्यातील एखादे नाव resolve करण्याचा हा अधिकार आहे. cd ला याची आवश्यकता असते. तिच्याखालील file उघडतानाही याची आवश्यकता असते. Path मधील प्रत्येक directory ला x आवश्यक असतो. त्यामुळे mode 644 असलेली file देखील तुमच्यासाठी unreachable राहते, जर वरील एखाद्या directory मध्ये तुमच्यासाठी x नसेल. Lookup कुठे थांबतो हे पाहण्यासाठी namei -l /path/to/file वापरा. हा command chain मधील प्रत्येक directory चा mode दाखवतो.
chmod 777 कधी योग्य उपाय असतो का?
Server वर जवळजवळ कधीच नाही. यामुळे machine वरील प्रत्येक account ला write permission मिळते. Services ज्या accounts अंतर्गत चालतात त्यांचाही यात समावेश होतो. त्यामुळे एखादी breached service file पुन्हा लिहू शकते. एखाद्या application ला directory मध्ये write करता येत नसेल, तर खरी समस्या बहुतेक वेळा ownership ची असते: mode 755 असलेले sudo chown -R appuser:appuser /srv/app/storage application ला आवश्यक access देते आणि इतर सर्वांना दूर ठेवते. परिचित अपवाद /tmp हा 1777 वर आहे. हे केवळ sticky bit मुळे कार्य करते, कारण sticky bit मुळे users ना एकमेकांच्या files delete करता येत नाहीत.
ls permissions नंतर dot किंवा plus का दाखवतो?
अकरावे character नऊ permission bits च्या पलीकडील rules दर्शवते. drwxr-xr-x. प्रमाणे dot असल्यास SELinux security context जोडलेला असतो. Fedora आणि Rocky वर हे सामान्य आहे. drwxr-xr-x+ प्रमाणे plus असल्यास POSIX ACL (access control list) सेट केलेली असते. त्यामुळे तीन triads मध्ये न दिसणाऱ्या rights एखाद्या user किंवा group कडे असू शकतात. त्या अतिरिक्त entries ची यादी करण्यासाठी getfacl <path> चालवा.