लिनक्स - क्या किसी फ़ाइल को रूट द्वारा भी डिलीट होने से रोकने / सुरक्षित करने का कोई तरीका है?

Question

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

Comments

ताकि आप इसे बहाल कर सकते हैं एक बैकअप बनाने, ... उसके अलावा, chattr +iमदद कर सकता है, लेकिन फ़ाइल केवल पढ़ने के रूप में अच्छी तरह से (और साथ ओवरराइड किया जा सकता कर देगा chattr -i), यह भी आप SELinux आदि के साथ यह संरक्षित करने के लिए कोशिश कर सकते हैं

— स्वेन

क्या रूट एक ऐसी प्रक्रिया बना सकता है जो रूट भी नहीं मार सकता है?

— मार्क गेब्रियल

@MarkGabriel हां। एक कांटा बम। :)

— 14

भगवान, जड़, क्या अंतर है?

— दान नीली

HW व्यवस्थापक आ सकता है और डिस्क को हटा सकता है, इसे काट सकता है, अवशेषों को जला सकता है और उन्हें hoghs को खिला सकता है। या, बेहतर, कुछ C (++) प्रोग्रामर कुछ नाक राक्षसों को प्रेरित कर सकता है। जो भी आपके लिए महत्वपूर्ण है, उसे वापस करें। दो बार।

— पावेल

Answer 1

हां, आप फ़ाइल की विशेषताओं को केवल पढ़ने के लिए बदल सकते हैं।

आदेश है:

chattr +i filename

और इसे निष्क्रिय करने के लिए:

chattr -i filename

से man chattr:

iविशेषता वाली फ़ाइल को संशोधित नहीं किया जा सकता है: इसे हटाया या नाम बदला नहीं जा सकता है, इस फ़ाइल का कोई लिंक नहीं बनाया जा सकता है और फ़ाइल में कोई डेटा नहीं लिखा जा सकता है। केवल सुपरसुसर या CAP_LINUX_IMMUTABLEक्षमता रखने वाली प्रक्रिया ही इस विशेषता को निर्धारित या साफ़ कर सकती है।

Comments

इच्छुक लोगों के लिए, bsd समतुल्य हैchflags schg

— एंड्रयू डॉमासेक

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

— अनुदान

@ नहीं, अगर सिक्योरवेल पर्याप्त उच्च सेट नहीं है। बूट प्रक्रिया नेटवर्क को सक्षम करने से पहले सुरक्षित करने के लिए 2 सेट करती है, इसलिए ध्वज को रीसेट करने के लिए स्थानीय मशीन एक्सेस की आवश्यकता होती है (लेकिन इसका मतलब यह है कि उस समय से पहले बूट प्रक्रिया में उपयोग की जाने वाली फाइलें अपरिवर्तनीय होने के साथ ही आवश्यक हैं)।

— शमौन रिक्टर

@ यदि कोई इसे चरम पर ले जाना चाहता है, तो आप यह नहीं रोक सकते कि विभाजन हटा दिया गया है या डिस्क को एक भट्टी या प्रोटॉन के क्षय में 10 ^ 30 वर्ष में डाल दिया गया है ...

— Hagen von Eitzen

@ इति गनोत यार काश मैंने इसे 4 दिन पहले पढ़ा होता। मैं एक परीक्षा में एक प्रश्न था जो मैंने लिया = /

— vfbsilva

Answer 2

इसे एक सीडी में जला दें। CD को CD-ROM ड्राइव में डालें और वहाँ से पहुँचें।

Comments

बॉक्स से बाहर सोचने के लिए +1। और, afaik, इसे कुछ परिस्थितियों में पहले भी इस्तेमाल किया गया है (ब्लैक-बॉक्स cdrom ड्राइव जिसमें cd के साथ इसे अपने गंतव्य पर भेज दिया गया है)। यह किसी को भी ड्राइव को डिस्कनेक्ट करने में सक्षम होने के लिए उपयुक्त नहीं हो सकता है।

— एलेक्स माज़रीओल

KISS मैं इसे प्यार करता! +1

— मंकीज़ियस

मुझे लगता है कि इस सवाल का सही जवाब है। फ़ाइल विशेषता बदलना (चैट -आई) दुर्भावनापूर्ण कार्यों को रोक नहीं सकता है।

— ब्रूनो वॉन पेरिस

इन दिनों एक बिल्ट-इन कार्डरीडर में एक पूर्ण आकार का एसडी कार्ड एक बेहतर समाधान हो सकता है - कम बिजली की खपत, कई मामलों में तेजी से पहुंच और नो-राइट उपयोग में अधिक टिकाऊ।

— क्रिस एच

@ jpmc26 इसलिए CD-ROM ड्राइव। जो पढ़े / ही हैं।

— थोरबजर्न रावन एंडरसन

Answer 3

1. एक फ़ाइल सिस्टम छवि बनाएँ।
2. छवि माउंट करें।
3. फ़ाइल को माउंट की गई छवि पर कॉपी करें।
4. छवि को अनमाउंट करें और इसे केवल-पढ़ने के लिए रिमाउंट करें।
5. अब आप इसे हटा नहीं सकते।

उदाहरण:

# dd if=/dev/zero of=readonly.img bs=1024 count=1024
# mkfs.ext2 readonly.img
# mkdir readonlyfolder
# mount readonly.img readonlyfolder/
# echo "can't delete this" > readonlyfolder/permanent.txt
# umount readonlyfolder
# mount -o ro readonly.img readonlyfolder
# cat readonlyfolder/permanent.txt 
can't delete this
# rm readonlyfolder/permanent.txt 
rm: cannot remove `readonlyfolder/permanent.txt': Read-only file system

Comments

mount -o remount,rw readonlyfolder/ && rm readonlyfolder/permanent.txt

— कज़ वुल्फ

इसे थोड़ा आगे बढ़ाते हुए, आप उपयोग कर सकते हैं squashfsया cramfsजो संपीड़ित हैं और केवल-पढ़ने के लिए। फाइलसिस्टम के निर्माण के लिए इसे एक विशेष टूल की आवश्यकता होती है।

— ज़ैन लिंक्स

Answer 4

लिनक्स में तथाकथित बाइंड-माउंट विकल्प है जो जानने के लिए शक्तिशाली और उपयोगी सुविधा है :

%  cd $TMP && mkdir usebindmountluke && cd usebindmountluke
%  echo usebindmountluke > preciousfile
%  sudo mount -B preciousfile preciousfile
%  sudo mount -oremount,ro preciousfile
%  echo sowhat > preciousfile
zsh: read-only file system: preciousfile
%  rm preciousfile
rm: cannot remove ‘preciousfile’: Read-only file system

- यहां जो कुछ किया जा रहा है वह अपने आप में बाइंड-माउंट फाइल है (हां, आप लिनक्स में ऐसा कर सकते हैं), फिर इसे आर / ओ-मोड में फिर से माउंट किया जाता है। बेशक यह निर्देशिका के लिए भी किया जा सकता है।

Answer 5

आपको फ़ाइल में कई हार्ड लिंक भी बनाने चाहिए। ये विभिन्न स्थानों पर होने चाहिए जो नियमित उपयोगकर्ता तक नहीं पहुंच सकते।

इस तरह, भले ही वे आपकी चैट प्रोटेक्शन को ओवरराइड करने का प्रबंधन करते हों, डेटा बना रहेगा और आप आसानी से इसे पुनर्स्थापित कर सकते हैं जहां आपका एप्लिकेशन इसे देख रहा है।

Comments

हार्ड लिंक फ़ाइल की सामग्री की सुरक्षा नहीं करेंगे।

— २००_सुफल

हालाँकि वे DELETION से अतिरिक्त सुरक्षा प्रदान करेंगे, जो कि मूल प्रश्न था।

— बारबेक्यू

@barbecue यदि फ़ाइल उस नाम से अनलिंक की जाती है जिस पर कोई एप्लिकेशन उसके लिए दिखता है, तो इससे कोई फर्क नहीं पड़ता कि फ़ाइल की सामग्री किसी अन्य नाम के तहत मौजूद है। अपेक्षित नाम वाली फ़ाइल की तलाश में किसी भी चीज़ के लिए, फ़ाइल अभी भी हटा दी गई है।

— बजे एक CVn

Answer 6

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

Comments

खैर, निश्चित रूप से फ़ाइल को नियमित रूप से बैकअप किया जा रहा है, मैं सिर्फ उन उपयोगकर्ताओं के खिलाफ सुरक्षा की एक और परत चाहता था जो कभी-कभी रूट पर अन्य अनुमतियों के साथ बॉक्स पर काम कर रहे हैं।

Answer 7

लिनक्स पर अडिग झंडा केवल फाइल सिस्टम के कुछ प्रकार पर समर्थित है (जैसे देशी लोगों के सबसे ext4, xfs, btrfs...)

फाइलसिस्टम पर जहां यह समर्थित नहीं है, एक अन्य विकल्प केवल-रीड मोड में फ़ाइल को अपने आप से बांधना है। यह दो चरणों में किया जाना है:

mount --bind file file
mount -o remount,bind,ro file

उदाहरण के लिए, हालांकि प्रत्येक बूट पर किया जाना है /etc/fstab।

Comments

मुझे उम्मीद है कि कोई भी umountफाइल फिर से लिखने की अनुमति प्राप्त

— करेगा

Answer 8

केविन द्वारा जवाब के लिए एक टिप्पणी में , जेरी का उल्लेख है:

खैर, निश्चित रूप से फ़ाइल को नियमित रूप से बैकअप किया जा रहा है, मैं सिर्फ उन उपयोगकर्ताओं के खिलाफ सुरक्षा की एक और परत चाहता था जो कभी-कभी रूट पर अन्य अनुमतियों के साथ बॉक्स पर काम कर रहे हैं। -

मैं यह मानकर चल रहा हूं कि आप इस प्रथा को नहीं बदल सकते, क्योंकि यह वास्तव में बहुत बुरा विचार है।

रीड-ओनली डिवाइस का उपयोग करने के बारे में सभी सुझावों में एक ही समस्या है - यह आपके लिए एक पीटीए बनाता है जब आपको आवश्यकता होती है तो वैध परिवर्तन करने के लिए। लॉक करने योग्य ड्राइव के मामले में, जैसे कि एसडी कार्ड, आप इस समस्या में भाग लेते हैं कि जब आप इसे बदलने के लिए इसे अनलॉक करते हैं तो आप अचानक कमजोर पड़ जाते हैं।

मैं इसके बजाय एनएफएस सर्वर के रूप में एक और मशीन स्थापित करने और मशीन (ओं) को महत्वपूर्ण फाइलों के साथ निर्देशिका साझा करने की सिफारिश करूंगा, जो उपयोगकर्ताओं के पास हैं। माउंट को केवल-पढ़ने के लिए साझा करें, ताकि जिन उपयोगकर्ताओं पर आपको भरोसा न हो उनके साथ मशीनें कोई संशोधन न कर सकें। जब आपको कानूनी रूप से बदलाव करने की आवश्यकता होती है, तो आप एनएफएस सर्वर से जुड़ सकते हैं और वहां हमारे बदलाव कर सकते हैं।

हम अपने वेबसर्वर्स के लिए इसका उपयोग करते हैं, ताकि वेबसर्वर के खिलाफ एक सफल शोषण किसी भी फाइल को डालने या बदलने में सक्षम नहीं होगा जो सर्वर तब वापस सेवा करेगा, या कॉन्फ़िगरेशन को बदल देगा।

ध्यान दें कि यह उसी तरह से बाईपास किया जा सकता है जिस तरह से माउंट-पॉइंट से संबंधित सभी हो सकते हैं:

• संरक्षित निर्देशिका की एक प्रति बनाएँ
• निर्देशिका को अनमाउंट करें
• यदि माउंट में पर्याप्त स्थान नहीं है, तो माउंट के स्थान पर प्रतिलिपि को ले जाएं, या इसे सहानुभूति दें।

Comments

एक महत्वपूर्ण फ़ाइल को नियमित रूप से बैकअप लेने और आकस्मिक विलोपन के खिलाफ मूल की रक्षा करने का प्रयास करने के लिए यह "वास्तव में, वास्तव में बुरा विचार" क्यों है? ओपी के मूल प्रश्न में, और आपके द्वारा संदर्भित उत्तर पर ओपी की टिप्पणी से, यह स्पष्ट है कि चिंता कोई दुर्भावनापूर्ण गतिविधि नहीं है, बल्कि आकस्मिक / अक्षम गतिविधि है।

— क्रेग

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

— जो एच।

आह ... अच्छी तरह से यह है। :-) लेकिन यह ओपी के सवाल का नहीं था। ओपी ने कहा कि रूट एक्सेस वाले उपयोगकर्ता हैं , जिन्हें गलती से किसी फ़ाइल को हटाने से बचाया जाना चाहिए।

— क्रेग

@Craig: यह सवाल की जड़ नहीं हो सकता है, लेकिन यह है समस्या (XY समस्या?) की जड़ ... लेकिन मैं पता नहीं क्या वे रूट के रूप में कर रहे हैं है, इसलिए अगर वे setuid का उपयोग कर सकता और / या सीमित sudo विशेषाधिकार। और आपको प्रश्न को फिर से पढ़ना चाहिए, जैसा कि मुझे जेरी द्वारा कोई उल्लेख नहीं दिखता है कि वह केवल अनजाने में हटाने के खिलाफ की रक्षा करने की कोशिश कर रहा है ("मुझे यह सुनिश्चित करने की आवश्यकता है कि यह जो भी हटा नहीं है"), और उसने केवल एक अनुवर्ती दिया कि मैं देखें (जिसने मेरी प्रतिक्रिया को ट्रिगर किया)।

— जो एच।

इस जवाब पर ओपी की प्रतिक्रिया देखें

— क्रेग

Answer 9

एक आईएसओ 9660 छवि क्यों नहीं बनाई गई है, जो केवल डिजाइन द्वारा पढ़ी जाती है?

आईएसओ छवि को माउंट करें, और यह सीडी-रॉम की तरह दिखेगा, लेकिन हार्ड ड्राइव के प्रदर्शन के साथ, और माउंटेड छवि पर फाइलें भौतिक सीडी-रॉम पर फ़ाइलों के रूप में डिलीट से सुरक्षित होंगी।

एक सीडी में संवेदनशील फाइल को जलाने और एक सीडी-रॉम से चलाने का विचार दिलचस्प है, यह मानते हुए कि फ़ाइल पर अपरिवर्तनीय बिट की स्थापना पर्याप्त नहीं है।

एक भौतिक सीडी को चलाने के साथ संभावित नकारात्मक मुद्दे हैं, जिसमें प्रदर्शन (सीडी-रोम ड्राइव बहुत अधिक है, हार्ड ड्राइव या एसएसडी की तुलना में बहुत धीमा है)। सीडी-रॉम की संभावना को एक अच्छी तरह से अलग-अलग व्यक्ति द्वारा हटाया जा रहा है और एक अलग डिस्क के साथ प्रतिस्थापित किया गया है जिसकी उन्हें आवश्यकता है। एक दुर्भावनापूर्ण पार्टी की संभावना है कि वह डिस्क को निकाल ले और उसे माइक्रोवेव (या कूड़ेदान) में फेंक दे, इस प्रकार आपकी फ़ाइल को "डिलीट" कर सकता है। वहाँ सिर्फ एक फ़ाइल और अन्य कारकों के लिए एक समर्पित हार्डवेयर CD-ROM ड्राइव होने की असुविधा है।

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

ऐसा लगता है कि माउंटेड आईएसओ इमेज से फाइल चलाने से आवश्यकता पूरी होगी।

Comments

रूट अभी भी सीधे छवि में हेरफेर करके किसी फ़ाइल को हटा सकता है। यह केवल एक सामान्य फ़ाइल है जो माउंट किया जाना है।

— थोरबजोरन रावन एंडरसन

@ ThorbjørnRavnAndersen कैसे? डिजाइन द्वारा आईएसओ 9660 अपरिवर्तनीय है। उस परिवर्तन को करने वाली पार्टी को पूरी ISO फ़ाइल को हटाना और बदलना होगा। ऐसा नहीं है कि वे ऐसा नहीं कर सकते। लेकिन वे अंदर नहीं जा सके और सर्जिकल रूप से जबरदस्त विशेषज्ञता के बिना एक फ़ाइल को हटा सकते हैं, यदि तब भी। एक ड्राइव से एक भौतिक सीडी-रॉम को निकालना और डंपस्टर में टॉस करना बहुत आसान होगा। ;-)

— क्रेग

परिष्कृत होने की आवश्यकता नहीं है - बस छवि फ़ाइल को शून्य के साथ ओवरराइट करें।

— थोरबजर्न रावन एंडरसन

@ ThorbjørnRavnAndersen मैं उस बिंदु को आसानी से पर्याप्त मान लूंगा। चेतावनी यह है कि इसे जानबूझकर छवि को खराब करने और इसे अधिलेखित करने की आवश्यकता होगी। एक पूरी तरह से shredयह सिर्फ उस बिंदु पर होगा। लेकिन जब तक आप मशीन तक भौतिक पहुंच से इनकार नहीं कर रहे हैं, तब भी ड्राइव के बाहर एक भौतिक सीडी को पॉप करना आसान है और डंपस्टर में टॉस करना है और आईएसओ फाइल को ओवरराइट और ओवरराइट करने की तुलना में आसान है, हालांकि या तो आसान है। और ओपी ने कहा है कि महत्वपूर्ण फ़ाइल को नियमित आधार पर बैकअप किया जाता है, इसलिए यह आकस्मिक क्षति के खिलाफ केवल एक अतिरिक्त उपाय है, न कि दुर्भावनापूर्ण शरारत के खिलाफ।

— क्रेग

मैंने बताया है कि ISO9660 छवि को कैसे बदलना है, भले ही वह अपरिवर्तनीय माना जाए। मेरा कहना यह है कि अगर थोड़ा सा भी लिखने योग्य है, तो रूट इसे लिख सकता है।

— थोरबजोरन रेव एंडरसन