आपको सीधे / आदि / छाया फ़ाइल को संपादित क्यों नहीं करना चाहिए?

10

यूनिक्स और लिनक्स स्टैक एक्सचेंज पर यहां एक अन्य जवाब में माइकल डी पार्कर ने लिखा , किसी ने जवाब में कहा कि ऐसा करना "सुरक्षित" था:

आमतौर पर आपको सीधे / आदि / छाया फ़ाइल को संपादित करना चाहिए।

इसलिए:

तुम क्यों चाहिए कभी नहीं संपादित /etc/shadowसीधे फ़ाइल?

password

— कैमरन पर दावा करें
स्रोत

क्योंकि इसमें आपके पासवर्ड एन्क्रिप्टेड हैं।

— मिलिंद डुम्बरे

7

क्योंकि आप इसे तोड़ देंगे। शायद आज नहीं, शायद कल नहीं, लेकिन जल्द ही

— ctrl-alt-delor

1

अपने प्रश्न को अपडेट करें (इसे संपादित करके) इस लिंक के साथ कि आपको ऐसा क्यों लगता है। मैं संपादन किया गया है /etc/shadowएक समस्या के बिना 20 साल के लिए, कभी । और कृपया दो मिनट की मदद से पढ़ने के लिए बहुत विनम्र बनें → टूर , विशेष रूप से "नो डिस्ट्रैक्शन", "नो चिट-चैट"। यह पहली बार है जब मुझे प्रश्न प्रासंगिक "विवरण" के माध्यम से पढ़ने की तुलना में एक प्रश्न में अधिक गैर-प्रासंगिक चिट-चैट के माध्यम से पढ़ना पड़ा।

— एंथन

"आमतौर पर आपको कभी नहीं" को "कभी नहीं" के समान नहीं होना चाहिए।

— रोइमा

2

@ कपट बकवास। ऐसा न करने के अच्छे कारण हैं। सिर्फ इसलिए कि आप किसी के बारे में नहीं सोच सकते हैं कि आप दूसरे लोगों को अज्ञानी कह सकते हैं। कृपया अच्छे रहें ।

— गिल्स एसओ- बुराई को रोकना '

15

इसके कई कारण संपादित करने के लिए नहीं कर रहे हैं /etc/passwd, /etc/shadow, /etc/group, /etc/gshadowया /etc/sudoersसीधे, बल्कि का उपयोग vipw, vigrया visudo:

यदि आप एक सिंटैक्स त्रुटि करते हैं, तो आप अब लॉग इन या रूट नहीं हो सकते हैं। ViXXX टूल का उपयोग करने से यह जोखिम कम हो जाता है क्योंकि फ़ाइल को संशोधित करने से पहले यह उपकरण शुद्धता की जांच करता है।
यदि फ़ाइल समवर्ती रूप से संपादित की जाती है, तो जो भी अंतिम बचाती है वह पिछले संपादन द्वारा किए गए परिवर्तनों को ओवरराइड कर देगी। इसमें फ़ाइल को संपादित करने वाला एक प्रशासक और फ़ाइल को संशोधित किया जाना शामिल है passwd, क्योंकि एक उपयोगकर्ता को बुलाया जाता है , chshया chfnउनके खाते के बारे में कुछ बदलना होता है। यदि आप उपयुक्त उपकरण का उपयोग करते हैं, तो यह समवर्ती संशोधनों को रोक देगा। यह ज्यादातर उपयोगकर्ताओं के साथ सिस्टम पर एक चिंता का विषय है, इससे कम यदि आप केवल उपयोगकर्ता हैं।
कुछ सिस्टम पर (ज्यादातर या केवल * बीएसडी), vipwकई फाइलों (जैसे /etc/passwdऔर /etc/master.passwd) को अपडेट करता है । यह लिनक्स पर लागू नहीं होता है।
vipwस्वचालित रूप से एक बैकअप ( passwd-, shadow-…,) बनाता है , जो उपयोगी है यदि आपको एहसास है कि आपने गलती से एक पंक्ति को हटा दिया है। यह केवल तभी उपयोगी होता है जब आपको अगले एडिट से पहले एहसास होता है, इसलिए यह संस्करण नियंत्रण और बैकअप को प्रतिस्थापित नहीं करता है, लेकिन यह बहुत अच्छा हो सकता है यदि आपको अपनी गलती का जल्द ही एहसास हो जाए। visudoयह नहीं करता है।

आप फ़ाइल को सीधे संपादित कर सकते हैं। आप बिना किसी वास्तविक लाभ के बस एक अतिरिक्त जोखिम लेंगे।

— गिल्स 'SO- बुराई होना बंद करो'
स्रोत

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

— JdeBP

3

और बीएसडी पर इसके साथ प्रमुख समस्या है, बल्कि, /etc/shadowयह मौजूद नहीं है और /etc/passwdसंपादित करने के लिए गलत फ़ाइल है, क्योंकि यह एक उत्पन्न फ़ाइल है जो स्रोत फ़ाइल नहीं है। B

— JdeBP

@JdeBP को छोड़कर यह कोई समस्या नहीं है और Master.passwd में BSDs की दुकान है

— Rob

6

इसे देखने के लिए मूल रूप से दो तरीके हैं:

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

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

बजाय पैकेज प्रबंधन डेटाबेस के साथ कुछ अन्य गलती के बाद मेरी समस्या हुई, पैकेज प्रबंधक ने बैकअप को सहेजे बिना इसे अधिलेखित करने का नेतृत्व किया और सिस्टम पर सभी उपयोगकर्ताओं को कटपुत कर दिया गया । आगे की मरम्मत में अज्ञानतावश घिनौने प्रयासों ने अन्य संबंधित फाइलों को नुकसान पहुँचाया और इससे पहले कि मैं /etcएक (उम्मीद से कम हाल ही में) बैकअप से पाठ फ़ाइलों के बहुमत को पुनर्स्थापित करने के लिए लंबे समय से पहले नहीं था ।

एक बार जब मैंने ऐसा कर लिया और सत्यापित किया कि मेरे पास यह कार्यशील स्थिति में है, तो मैंने जानबूझकर, सावधानीपूर्वक यह सब फिर से करने का फैसला किया। और एक बार और। यह सब कुछ महीने पहले था, लेकिन आज मुझे विश्वास है कि मैं loginअपने सिस्टम पर किसी एकल लॉगफाइल के w / एक बार के मुद्दे का निदान कर सकता हूं और इसे किसी भी मूल संपादक के साथ संबोधित कर सकता हूं (और, शायद, एक नज़र या दो man 5 problem_file) ने प्रभावित रूट रूट एफएस को केवल बुनियादी पहुंच प्रदान की। यह सस्ते में प्राप्त नहीं हुआ था - यह मुझे एक दिन में सबसे अधिक समय लगा - और संबंधित कॉन्फिग फाइलों को निर्देशिका में (और यहां तक कि कुछ - जैसे कि लिनक्स पैम के /var/run/no_login- अन्य माउंट पर) फैलाया जाता है - लेकिन यह करने लायक था। और यह थोड़े से पूर्वाभास से सस्ता हो सकता था।

इस कहानी का नैतिक कि यह शायद है नहीं एक अच्छी बात है कि जैसे मिशन के लिए महत्वपूर्ण कॉन्फ़िगरेशन का स्वरूप shadow, passwd, groups, shellsइसलिए हमारे लिए अपारदर्शी है कि हम विशेष उपकरण संपादित करें कि या तरीकों से हमारे काम को सही नहीं हो सकता है रोजगार चाहिए होना चाहिए और कारणों से हम एक साधारण परिवर्तन को प्रभावित करने के लिए नहीं समझते हैं। कम से कम, मुझे लगता है, यह समझने के लिए हमारे लायक है कि हम जो कर सकते हैं, उससे अलग वे क्या करेंगे।

यह शायद है एक अच्छी बात है, तथापि, संपादन के साथ एक बार हम बन परिचित पर्याप्त ने कहा कि है कि हम उन के भीतर कर रहे हैं और बाद में उन्हें बचत टंकण या सरल वाक्यात्मक त्रुटियों हमारे निपटान में उपकरण जो कर सकते हैं इस बात की दोबारा जांच देखते हैं कि का जोखिम हो सकता फ़ाइलें हमारे काम के तरीकों और कारणों के लिए हम पहले से ही हमारे blase संपादन को लागू करने से पहले समझते हैं।

— mikeserv
स्रोत

3

काउंटर पॉइंट - यदि आपको अपने वर्तमान पासवर्ड को जानने या उन्हें नए लोगों को असाइन किए बिना, एक सर्वर से दूसरे में एक उपयोगकर्ता लॉगिन के एक सेट की प्रतिलिपि बनाने की आवश्यकता है, तो आपको सीधे हैशेड पासवर्ड फ़ील्ड सम्मिलित करने के लिए / आदि / छाया को संपादित करने की आवश्यकता होगी। vipw आपको उस क्षेत्र को छूने नहीं देता है, यह सिर्फ "*" है

अद्यतन: या इस मामले में chpasswd -e "हैशेड पासवर्ड" का उपयोग करें, लेकिन यह केवल सीधे कंप्यूटर पर किया जा सकता है। यदि आप उन फ़ाइलों के एक सेट के साथ काम कर रहे थे जिन्हें अभी तक एक मशीन (जैसे वर्चुअल मशीन) पर तैनात किया जाना है, तो सीधे संपादन केवल एकमात्र समाधान हो सकता है।

यानी आम तौर पर संपादन / आदि / छाया के बिना आप जो करना चाहते हैं, उसके लिए एक उपकरण है, आपको बस यह जानना होगा कि यह क्या है ...

— Tomuo
स्रोत

या आप एक LDAP सर्वर सेट कर सकते हैं।

— Kusalananda

0

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

कभी मत कहो ... जब तक तुम्हारा मतलब नहीं है।

— Bigtexun
स्रोत