Chmod समझाया गया: आपकी फ़ाइलों और फ़ोल्डरों के लिए गुप्त हैंडशेक

एक वाक्य में

chmod एक Unix कमांड है जो यह परिभाषित करता है कि कौन किसी फ़ाइल को read, write, या execute कर सकता है, और यह दुनिया के अधिकांश सर्वरों और डेवलपर मशीनों के लिए मूलभूत एक्सेस कंट्रोल सिस्टम के रूप में काम करता है।

यह क्या समस्या हल करता है

कंप्यूटिंग के शुरुआती दिनों की कल्पना करें: एक व्यक्ति, एक मशीन, एक समय में एक काम। ऐसे सिस्टम पर, फ़ाइल अनुमतियाँ एक ऐसी समस्या का समाधान थीं जिसकी कोई समस्या ही नहीं थी। यदि आप ही एकमात्र व्यक्ति हैं जो कभी कंप्यूटर का उपयोग करेंगे, तो आप फ़ाइलों को किससे बचा रहे हैं? खुद से?

फिर 1960 के दशक के अंत में बेल लैब्स में Unix आया। इसका क्रांतिकारी विचार शुरू से ही एक मल्टी-यूज़र, मल्टी-टास्किंग ऑपरेटिंग सिस्टम बनना था। अचानक, आपके पास एक ही मेनफ्रेम कंप्यूटर में अलग-अलग टर्मिनलों के माध्यम से कई प्रोग्रामर एक ही समय में काम कर रहे थे। इसने एक नई और तत्काल समस्या पैदा की: आप डेनिस को केन के नए C कंपाइलर को गलती से (या "गलती से") हटाने से कैसे रोकते हैं? आप अपने प्रोजेक्ट पार्टनर को अपना कोड पढ़ने की अनुमति कैसे देते हैं लेकिन उन्हें इसे बदलने से कैसे रोकते हैं? आप कोर ऑपरेटिंग सिस्टम फ़ाइलों को एक अनाड़ी इंटर्न से कैसे बचाते हैं?

इसका समाधान फ़ाइल सिस्टम में ही स्वामित्व और अनुमतियों की एक सुंदर सरल और मजबूत प्रणाली थी। प्रत्येक फ़ाइल और डायरेक्टरी का एक मालिक होगा, एक समूह से संबंधित होगा, और तीन वर्गों के उपयोगकर्ताओं के लिए अनुमतियों का एक विशिष्ट सेट होगा: मालिक, समूह के सदस्य, और बाकी सभी।

किसी फ़ाइल के "मोड को बदलने" (change the mode) - यानी, इन अनुमतियों को संशोधित करने - के लिए कमांड का नाम chmod रखा गया। यह सिस्टम एडमिनिस्ट्रेटर और उपयोगकर्ताओं के लिए यह घोषित करने का सार्वभौमिक उपकरण बन गया, "यह फ़ाइल मेरी है, और इसके साथ इंटरैक्ट करने के नियम ये हैं।" इसने मल्टी-यूज़र अराजकता की समस्या को इतनी प्रभावी ढंग से हल किया कि आज भी लगभग हर लिनक्स सर्वर, macOS मशीन, एंड्रॉइड फोन और ग्रह पर IoT डिवाइस पर वही कोर मॉडल उपयोग किया जाता है।

अंदर से यह कैसे काम करता है

अपने मूल में, chmod सिस्टम नियमों का एक 3x3 ग्रिड है, जिसमें कुछ विशेष फ़्लैग भी हैं। इसे समझने के लिए, आपको तीन प्रकार की अनुमतियों और तीन वर्गों के उपयोगकर्ताओं को समझना होगा जिन पर वे लागू हो सकते हैं।

तीन अनुमतियाँ: Read, Write, Execute

सब कुछ तीन बुनियादी क्रियाओं के इर्द-गिर्द घूमता है जो आप किसी फ़ाइल या डायरेक्टरी पर कर सकते हैं। उन्हें r, w, और x अक्षरों द्वारा दर्शाया जाता है।

Read (r): किसी फ़ाइल की सामग्री को खोलने और देखने की क्षमता।
Write (w): किसी फ़ाइल की सामग्री को संशोधित करने, बदलने या हटाने की क्षमता।
Execute (x): फ़ाइल को प्रोग्राम या स्क्रिप्ट के रूप में चलाने की क्षमता।

लेकिन यहाँ पहली "समस्या" है: इन अनुमतियों का एक डायरेक्टरी के लिए थोड़ा अलग मतलब होता है। यह भ्रम का एक बहुत ही सामान्य बिंदु है।

अनुमति	एक फ़ाइल पर	एक डायरेक्टरी पर
Read (`r`)	फ़ाइल की सामग्री देख सकते हैं	डायरेक्टरी में फ़ाइलों के नाम सूचीबद्ध कर सकते हैं (`ls`)
Write (`w`)	फ़ाइल की सामग्री बदल सकते हैं	डायरेक्टरी के भीतर फ़ाइलें बना सकते हैं, उनका नाम बदल सकते हैं, या हटा सकते हैं
Execute (`x`)	फ़ाइल चला सकते हैं	डायरेक्टरी में प्रवेश कर सकते हैं (`cd`) और उसके अंदर की फ़ाइलों तक पहुँच सकते हैं

उस आखिरी वाले के बारे में सोचें। यदि किसी डायरेक्टरी में आपके लिए execute की अनुमति नहीं है, तो आप उसमें cd नहीं कर सकते, भले ही आप उसकी सामग्री देख सकें! आपको डायरेक्टरी के "दरवाजे" से गुजरने के लिए x की आवश्यकता है।

तीन उपयोगकर्ता वर्ग: Owner, Group, Others

Unix अनुमतियाँ सार्वभौमिक नहीं हैं; वे उपयोगकर्ताओं की विशिष्ट श्रेणियों को सौंपी जाती हैं।

Owner (u): एक एकल उपयोगकर्ता जो फ़ाइल का मालिक है। आमतौर पर, यह वह व्यक्ति होता है जिसने इसे बनाया है। मालिक का सबसे अधिक नियंत्रण होता है।
Group (g): प्रत्येक फ़ाइल एक समूह से संबंधित होती है। यह मालिक को विशिष्ट टीम के सदस्यों के साथ पहुँच साझा करने की अनुमति देता है। उदाहरण के लिए, "प्रोजेक्ट अपोलो" की सभी फ़ाइलें apollo-devs समूह की हो सकती हैं।
Others (o): सचमुच बाकी सब कोई। सिस्टम पर कोई भी उपयोगकर्ता जो मालिक नहीं है और फ़ाइल के समूह से संबंधित नहीं है।

जब आप rwxr-xr-- जैसी अनुमति स्ट्रिंग देखते हैं, तो यह वास्तव में Owner, Group, और Others के लिए rwx अनुमतियों के तीन सेट हैं, जो इसी क्रम में एक साथ रखे गए हैं।

rwx: Owner पढ़, लिख और एक्सेक्यूट कर सकता है।
r-x: Group पढ़ और एक्सेक्यूट कर सकता है, लेकिन लिख नहीं सकता।
r--: Others केवल पढ़ सकते हैं।

दो नोटेशन: Symbolic बनाम Octal

chmod को यह बताने के दो तरीके हैं कि आप क्या चाहते हैं, और डेवलपर्स हमेशा उनके बीच अनुवाद करते रहते हैं।

1. Symbolic Notation (the "friendly" way) Symbolic notation उन अक्षरों का उपयोग करता है जिन्हें हम पहले ही सीख चुके हैं (r, w, x और u, g, o, a जहाँ a का अर्थ "all" है)। आप अनुमति जोड़ने के लिए + का उपयोग करते हैं, इसे हटाने के लिए -, और इसे ठीक से सेट करने के लिए =।

# मालिक को execute की अनुमति दें
$ chmod u+x my_script.sh

# समूह और अन्य लोगों के लिए लिखने की अनुमति हटा दें
$ chmod go-w sensitive_data.txt

# अनुमतियों को ठीक से सेट करें: मालिक पढ़/लिख सकता है, समूह पढ़ सकता है, दूसरों के पास कोई पहुँच नहीं है
$ chmod u=rw,g=r,o= config.yml

यह छोटे, लक्षित परिवर्तन करने के लिए बहुत अच्छा है।

2. Octal Notation (the "nerdy" way) Octal तेज है, स्क्रिप्ट में अधिक आम है, और बाइनरी पर आधारित है। प्रत्येक अनुमति (r, w, x) 3-बिट संख्या में एक बिट है।

r (read) पहला बिट है, जिसका मान 4 है।
w (write) दूसरा बिट है, जिसका मान 2 है।
x (execute) तीसरा बिट है, जिसका मान 1 है।

आप उन अनुमतियों के लिए संख्याओं को एक साथ जोड़ते हैं जो आप चाहते हैं।

संख्या	बाइनरी (`rwx`)	दी गई अनुमतियाँ
0	`000` (`---`)	कोई नहीं
1	`001` (`--x`)	Execute
2	`010` (`-w-`)	Write
3	`011` (`-wx`)	Write and execute
4	`100` (`r--`)	Read
5	`101` (`r-x`)	Read and execute
6	`110` (`rw-`)	Read and write
7	`111` (`rwx`)	Read, write, execute

755 जैसा तीन-अंकीय ऑक्टल कोड Owner, Group, और Others के लिए अनुमतियों का प्रतिनिधित्व करता है।

chmod 755 my_script.sh का अर्थ है:

Owner: 7 (rwx) - Read, write, and execute.
Group: 5 (r-x) - Read and execute.
Others: 5 (r-x) - Read and execute.

यह एक्सेक्यूटेबल स्क्रिप्ट के लिए एक बहुत ही सामान्य अनुमति है जो दूसरों के लिए चलाने के लिए सुरक्षित है। किसी फ़ाइल के लिए एक सामान्य अनुमति 644 है (मालिक पढ़/लिख सकता है, बाकी सब केवल पढ़ सकते हैं)।

विशेष मेहमान: SUID, SGID, और Sticky Bit

बुनियादी rwx के अलावा, तीन विशेष मोड हैं, जिन्हें शुरुआत में चौथे ऑक्टल अंक द्वारा दर्शाया जाता है (उदाहरण के लिए, chmod 4755)।

SUID (Set User ID) - ऑक्टल 4: जब इस बिट वाली एक एक्सेक्यूटेबल फ़ाइल चलाई जाती है, तो यह फ़ाइल के मालिक की अनुमतियों के साथ चलती है, न कि उस उपयोगकर्ता की जिसने इसे चलाया है। इसका क्लासिक उदाहरण passwd कमांड है, जिसे संरक्षित /etc/shadow फ़ाइल को संशोधित करने की आवश्यकता होती है। passwd एक्सेक्यूटेबल का मालिक root है और इसमें SUID बिट सेट है, इसलिए जब एक सामान्य उपयोगकर्ता इसे चलाता है, तो यह उस एक ऑपरेशन के लिए अस्थायी रूप से रूट विशेषाधिकार प्राप्त कर लेता है। यह शक्तिशाली है लेकिन खतरनाक है।
SGID (Set Group ID) - ऑक्टल 2: SUID के समान, लेकिन एक एक्सेक्यूटेबल फ़ाइल के समूह की पहचान के साथ चलता है। अधिक उपयोगी रूप से, जब किसी डायरेक्टरी पर सेट किया जाता है, तो इसके अंदर बनाई गई कोई भी नई फ़ाइल या डायरेक्टरी स्वचालित रूप से पैरेंट डायरेक्टरी के समूह को इनहेरिट करेगी, न कि बनाने वाले उपयोगकर्ता के प्राथमिक समूह को। यह साझा प्रोजेक्ट फ़ोल्डरों के लिए आवश्यक है।
Sticky Bit - ऑक्टल 1: इसका एक अजीब इतिहास है, लेकिन आज यह लगभग विशेष रूप से डायरेक्ट्रीज पर उपयोग किया जाता है। जब किसी डायरेक्टरी में स्टिकी बिट होता है (जैसे सिस्टम के /tmp फ़ोल्डर), तो सभी उपयोगकर्ता इसमें फ़ाइलें बना सकते हैं, लेकिन एक उपयोगकर्ता केवल उन फ़ाइलों को हटा या नाम बदल सकता है जिनका वह स्वयं मालिक है। यह लोगों को एक साझा स्थान में एक-दूसरे के सामान के साथ खिलवाड़ करने से रोकता है।

वास्तविक दुनिया की कहानियाँ

न चलने वाली स्क्रिप्ट का मामला

एक जूनियर डेवलपर, एलेक्स, सर्वर डिप्लॉयमेंट को स्वचालित करने के लिए एक शानदार शेल स्क्रिप्ट लिखता है। वह deploy.sh को Git में कमिट करता है। प्रोडक्शन सर्वर पर, वह रिपॉजिटरी को क्लोन करता है, ./deploy.sh टाइप करता है, और एंटर दबाता है। प्रतिक्रिया: bash: ./deploy.sh: Permission denied। घबराहट। क्या उसने सर्वर तोड़ दिया? एक सीनियर देव शांति से ls -l deploy.sh टाइप करता है और उसे आउटपुट दिखाता है: -rw-r--r--। फ़ाइल में पढ़ने और लिखने की अनुमति थी, लेकिन एक्सेक्यूट (x) की नहीं। Git डिफ़ॉल्ट रूप से एक्सेक्यूट अनुमतियों को संरक्षित नहीं करता है। एक त्वरित chmod +x deploy.sh के बाद, स्क्रिप्ट पूरी तरह से चल गई। सबक: फ़ाइलें, विशेष रूप से Git या ज़िप आर्काइव जैसे स्रोतों से, डिफ़ॉल्ट रूप से एक्सेक्यूटेबल नहीं होती हैं। आपको उन्हें चलाने के लिए स्पष्ट रूप से अनुमति देनी होगी।

साझा प्रोजेक्ट फ़ोल्डर का बुरा सपना

एक डिज़ाइन टीम और एक डेवलपमेंट टीम को लिनक्स सर्वर पर एक फ़ोल्डर में संपत्ति साझा करने की आवश्यकता थी: /data/project-x। sysadmin ने सभी को project-x-team समूह में डाल दिया और समूह को फ़ोल्डर में लिखने की पहुँच दी। लेकिन अराजकता फैल गई। जब एक डिज़ाइनर ने एक फ़ाइल अपलोड की, तो उसका मालिक designer:designers था, और देव उसे संशोधित नहीं कर सकते थे। जब एक देव ने एक सब-फ़ोल्डर बनाया, तो उसका मालिक dev:developers था, और डिज़ाइनर उसमें फ़ाइलें नहीं जोड़ सकते थे। हर कोई लगातार sysadmin से अनुमतियों को ठीक करने के लिए कह रहा था। समाधान? एडमिन ने chmod g+s /data/project-x चलाया। इसने डायरेक्टरी पर SGID बिट सेट कर दिया। तब से, /data/project-x के अंदर बनाई गई हर नई फ़ाइल और फ़ोल्डर ने स्वचालित रूप से project-x-team समूह को इनहेरिट कर लिया। सद्भाव बहाल हो गया। सबक: एक डायरेक्टरी पर SGID साझा समूह फ़ोल्डरों को प्रबंधित करने का सही, नॉन-हैकी तरीका है।

पब्लिक वेबसाइट में सुरक्षा की खामी

एक फ्रीलांस वेब डेवलपर ने एक क्लाइंट के लिए एक साधारण PHP वेबसाइट लॉन्च की। सुविधा के लिए, उसने डेटाबेस कॉन्फ़िगरेशन फ़ाइल, config.inc.php, को होमपेज के समान डायरेक्टरी में छोड़ दिया। फ़ाइल में सादे टेक्स्ट में डेटाबेस उपयोगकर्ता नाम और पासवर्ड था। इसकी अनुमतियाँ डिफ़ॉल्ट 644 (-rw-r--r--) थीं, जिसका मतलब था कि वेब सर्वर का उपयोगकर्ता इसे पढ़ सकता था (अच्छा), लेकिन ग्रह पर कोई भी व्यक्ति जो URL का अनुमान लगा सकता था, वह भी पढ़ सकता था। एक सुरक्षा स्कैनर ने फ़ाइल ढूंढ ली, और हमलावर ने डेटाबेस क्रेडेंशियल डाउनलोड कर लिए। इसका समाधान chmod 600 config.inc.php होना चाहिए था, जिससे यह केवल मालिक (वेब सर्वर प्रक्रिया) द्वारा पठनीय हो जाता। सबक: कभी यह न मानें कि डिफ़ॉल्ट अनुमतियाँ सुरक्षित हैं। कॉन्फिग्स और निजी कुंजियों जैसी संवेदनशील फ़ाइलों को यथासंभव प्रतिबंधात्मक बनाने के लिए लॉक किया जाना चाहिए।

आम गलतियाँ और जाल

chmod 777 का हथौड़ा। जब निराश हो जाते हैं, तो बहुत से लोग एक डायरेक्टरी पर chmod -R 777 . चलाने के लिए ललचाते हैं। यह पुनरावर्ती रूप से सभी को सब कुछ पढ़ने, लिखने और एक्सेक्यूट करने की अनुमति देता है। यह एक विनाशकारी सुरक्षा भेद्यता है और यह आपके घर के दरवाज़े निकालकर बाहर 'अंदर मुफ्त सामान है' का साइन लगाने जैसा है। ऐसा न करें।
डायरेक्टरी x अनुमति को भूलना। आपके पास किसी फ़ाइल पर r की अनुमति हो सकती है लेकिन आप उस तक नहीं पहुँच सकते क्योंकि आपके पास उसके पाथ में किसी एक पैरेंट डायरेक्टरी पर x की अनुमति नहीं है। आपको उन सभी डायरेक्ट्रीज पर एक्सेक्यूट की अनुमति की आवश्यकता है जिन्हें आप पार करना चाहते हैं।
umask का रहस्य। कभी सोचा है कि आपके द्वारा बनाई गई नई फ़ाइलें 644 क्यों होती हैं और 777 नहीं? यह आपका umask काम कर रहा है। umask एक "मास्क" है जिसे आपका शेल लागू करता है, जो फ़ाइलों और डायरेक्ट्रीज के बनते ही उनसे अनुमतियाँ हटा देता है। 022 का एक सामान्य umask समूह और अन्य के लिए "write" अनुमति को हटा देता है, जिससे एक डिफ़ॉल्ट 666 को 644 में बदल दिया जाता है।
यह सोचना कि chmod +x और chmod 755 एक ही चीज़ है। यह नहीं है। chmod 755 my_file अनुमतियों को बिल्कुल सेट करता है। chmod +x my_file किसी भी उपयोगकर्ता वर्ग (owner, group, other) के लिए एक्सेक्यूट बिट जोड़ता है जिसके पास पहले से ही रीड बिट है, बिना किसी अन्य बिट को बदले। Symbolic मोड सापेक्ष है; ऑक्टल मोड निरपेक्ष है।

यह आपके रडार पर क्यों होना चाहिए

यदि आप एक नॉन-विंडोज कमांड लाइन को छूते हैं, तो आपको chmod को समझने की आवश्यकता है। यह वैकल्पिक नहीं है। यह ज्ञान महत्वपूर्ण है जब:

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

chmod पहले और सबसे मौलिक कमांड में से एक है जो एक सामान्य उपयोगकर्ता को एक सच्चे सिस्टम ऑपरेटर या डेवलपर से अलग करता है। इसे समझना मशीन को केवल उपयोग करने के बजाय उसे नियंत्रित करने की दिशा में एक महत्वपूर्ण पड़ाव है।

और गहराई में जाएं

विकिपीडिया: chmod - कमांड, इसके इतिहास और इसके विभिन्न नोटेशन का एक शानदार उच्च-स्तरीय अवलोकन।
विकिपीडिया: File-system permissions - DAC, ACLs, और सिस्टम भर में सिम्बॉलिक/ऑक्टल नोटेशन की अवधारणाओं पर एक व्यापक नज़र।
The Linux man-pages project: chmod(1) - लिनक्स पर chmod कमांड के लिए कैनोनिकल, तकनीकी संदर्भ। सघन लेकिन आधिकारिक।
The Open Group Base Specifications (POSIX): chmod - वास्तविक मानक जो यह परिभाषित करता है कि chmod को किसी भी POSIX-अनुपालक सिस्टम (जैसे macOS और Linux) पर कैसा व्यवहार करना चाहिए।
आर्क विकी: File permissions and attributes - आर्क लिनक्स समुदाय से एक बहुत ही व्यावहारिक और अच्छी तरह से बनाए रखा गया गाइड, जिसमें chmod, chown, और विशेष विशेषताओं को शामिल किया गया है।