লিনাক্স - মূলত এমনকি কোনও ফাইল মুছে ফেলা থেকে রক্ষা / সুরক্ষা দেওয়ার কোনও উপায় আছে কি?

Question

আমার একটি খুব গুরুত্বপূর্ণ ফাইল রয়েছে যা আমার কর্মক্ষেত্রে একটি অ্যাপ্লিকেশন ব্যবহার করে, আমার এটি নিশ্চিত করা দরকার যে এটি কোনও কিছু মুছে ফেলা হচ্ছে না, আমি কীভাবে এটি করতে পারি?

Comments

তাই আপনি এটি পুনরুদ্ধার করতে পারেন একটি ব্যাকআপ করুন, ... অন্য যে, chattr +iসাহায্য করতে পারে কিন্তু ফাইল কেবল-পঠনযোগ্য পাশাপাশি (এবং সঙ্গে ওভাররাইড করা যেতে পারে করা হবে chattr -i), এছাড়াও আপনি SELinux ইত্যাদি সঙ্গে এটি সুরক্ষিত করার চেষ্টা করতে পারেন

— সেভেন

রুট এমন একটি প্রক্রিয়া তৈরি করতে পারে যা রুটও হত্যা করতে পারে না?

— গ্যাব্রিয়েল

@ মার্কগ্যাব্রিয়েল হ্যাঁ একটি কাঁটাচামচ বোমা। :)

— 14'7

Godশ্বর, রুট, পার্থক্য কি?

— ড্যান নীলি

এইচডাব্লু অ্যাডমিন এসে ডিস্কটি সরিয়ে ফেলতে পারে, এটিকে টুকরো টুকরো করে ফেলবে, অবশিষ্টাংশগুলি পুড়িয়ে ফেলবে এবং হাগগুলিতে খাওয়াত। বা আরও ভাল, কিছু সি (++) প্রোগ্রামার কিছু অনুনাসিক রাক্ষসকে প্ররোচিত করতে পারে। আপনার কাছে যা গুরুত্বপূর্ণ, তা ব্যাক আপ করুন। দুবার।

— পাভেল

Answer 1

হ্যাঁ, আপনি কেবলমাত্র পড়ার জন্য ফাইলের বৈশিষ্ট্যগুলি পরিবর্তন করতে পারেন।

আদেশটি হ'ল:

chattr +i filename

এবং এটি অক্ষম করতে:

chattr -i filename

থেকে man chattr:

iঅ্যাট্রিবিউটযুক্ত একটি ফাইল সংশোধন করা যায় না: এটি মোছা বা পুনরায় নামকরণ করা যায় না, এই ফাইলটিতে কোনও লিঙ্ক তৈরি করা যায় না এবং ফাইলটিতে কোনও ডেটাও লেখা যায় না। কেবলমাত্র সুপারভাইজার বা CAP_LINUX_IMMUTABLEসক্ষমতা সম্পন্ন একটি প্রক্রিয়া এই বৈশিষ্ট্যটি সেট বা সাফ করতে পারে।

Comments

আগ্রহীদের জন্য, chflags schg

— বিএসডি

মনে রাখবেন যে রুট অ্যাক্সেস সহ কোনও ব্যবহারকারী সেই পতাকাটি আনসেট করতে পারে এবং তারপরে ফাইলটি মুছতে পারে। দুর্ঘটনাক্রমে এটি হওয়ার সম্ভাবনা নেই তবে এটি ইচ্ছাকৃত মোছার বিরুদ্ধে ছাঁটাই করে না।

— অনুদান দিন

@ গ্রান্ট, সিকিউরিলেভেল যথেষ্ট পরিমাণে সেট করা থাকলে নয় । নেটওয়ার্ক সক্ষম হওয়ার আগে বুট প্রক্রিয়াটি সুরক্ষিত স্থানটি 2 তে সেট করে, তাই পতাকাটি পুনরায় সেট করতে স্থানীয় মেশিন অ্যাক্সেসের প্রয়োজন হয় (তবে এর অর্থ এই যে বুট প্রক্রিয়াতে ব্যবহৃত ফাইলগুলি সেই সময়ের আগেও অপরিবর্তনীয় হওয়া দরকার)।

— সাইমন রিখটার

@ গ্রান্ট যদি কেউ এটিকে চূড়ান্ত দিকে নিতে চায়, আপনি পার্টিশনটি মুছে ফেলা বা ডিস্কটিকে একটি চুল্লি বা প্রোটন ক্ষয় 10 বা 30 বছরে ফেলে দেওয়া আটকাতে পারবেন না ...

— হ্যাগেন ভন ইটজেন

@ ইটাই গানোট লোকটি আশা করি আমি 4 দিন আগে এটি পড়তে পারি। আমি একটি পরীক্ষায় আমি প্রশ্ন ছিলাম আমি = /

— vfbsilva

Answer 2

এটি একটি সিডি বার্ন করুন। একটি সিডি-রোম ড্রাইভে সিডি রাখুন এবং সেখান থেকে এটি অ্যাক্সেস করুন।

Comments

বাক্স থেকে চিন্তা করার জন্য +1। এবং আফাইক, এটি কিছু পরিস্থিতিতে এর আগেও ব্যবহার করা হয়েছিল (ব্ল্যাক-বাক্স সিড্রোম ড্রাইভ এতে সিডি দিয়ে তার গন্তব্যে প্রেরণ করা হয়েছিল)। কেউ যদি যাইহোক, ড্রাইভ সংযোগ বিচ্ছিন্ন করতে সক্ষম হন তবে এটি উপযুক্ত নাও হতে পারে।

— অ্যালেক্স মাজারিওল

আমি এটি ভালবাসি! +1

— MonkeyZeus

আমি মনে করি এটিই এই প্রশ্নের সঠিক উত্তর। ফাইল অ্যাট্রিবিউট (চ্যাটার-আই) পরিবর্তন করা দূষিত ক্রিয়াগুলি রোধ করতে পারে না।

— ব্রুনো ভন প্যারিস

এই দিন একটি অন্তর্নির্মিত কার্ডরিডারে একটি পূর্ণ আকারের এসডি কার্ড একটি ভাল সমাধান হতে পারে - কম বিদ্যুতের খরচ, অনেক ক্ষেত্রে দ্রুত অ্যাক্সেস এবং লেখার জন্য ব্যবহারের ক্ষেত্রে আরও টেকসই।

— ক্রিস এইচ

@ jpmc26 অতএব সিডি-রোম ড্রাইভ। এগুলি কেবল পঠনযোগ্য / পড়ার মতো।

— থরবজর্ন রাভন অ্যান্ডারসন

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

হার্ড লিঙ্কগুলি ফাইলের বিষয়বস্তু রক্ষা করবে না।

— 200_সাক্সেস

তবে তারা মুছে ফেলা থেকে অতিরিক্ত সুরক্ষা দেবে, যা ছিল আসল প্রশ্ন।

— বারবিকিউ

@ বারবিকিউ যদি ফাইলটি নামের সাথে লিঙ্কযুক্ত থাকে তবে একটি অ্যাপ্লিকেশন এটির জন্য সন্ধান করে, তাতে ফাইলের সামগ্রী অন্য কোনও নামে বিদ্যমান বলে কিছু যায় আসে না। প্রত্যাশিত নাম সহ ফাইলটির সন্ধানের জন্য ফাইলটি এখনও মুছে ফেলা হয়েছে।

— একটি সিভিএন

Answer 6

অন্যরা আপনার প্রশ্নের উত্তর যেমনভাবে জিজ্ঞাসা করেছেন তেমন উত্তর দিয়েছেন। @ সোভেন একটি মন্তব্যে যেমন উল্লেখ করেছেন, প্রশ্নের সাধারণ সমাধান, "আমি কীভাবে নিশ্চিত করব যে আমি কখনই কোনও ফাইল হারাব না?" ফাইলের ব্যাকআপ তৈরি করা। ফাইলটির একটি অনুলিপি তৈরি করুন এবং একাধিক জায়গায় সংরক্ষণ করুন। তদতিরিক্ত, যদি ফাইলটি অত্যন্ত গুরুত্বপূর্ণ এবং আপনার সংস্থার একটি ব্যাকআপ পরিষেবা সহ গুরুত্বপূর্ণ ডেটা ব্যাক আপ করার নীতি থাকে তবে আপনি এই ফাইলটিকে পরিষেবাতে অন্তর্ভুক্ত করে নিতে পারেন।

Comments

ঠিক আছে, অবশ্যই ফাইলটি নিয়মিত ব্যাক আপ হচ্ছে, আমি কেবল ব্যবহারকারীদের বিরুদ্ধে সুরক্ষার জন্য আরও একটি স্তর চেয়েছিলাম যা কখনও কখনও রুট ব্যবহারকারীর অনুমতি নিয়ে বাক্সে কাজ করে।

Answer 7

লিনাক্স উপর অপরিবর্তনীয় পতাকা শুধুমাত্র ফাইল সিস্টেম কিছু ধরনের সমর্থিত (যেমন নেটিভ বেশী অধিকাংশ ext4, xfs, btrfs...)

ফাইল-সিস্টেমগুলিতে যেখানে এটি সমর্থিত নয়, অন্য বিকল্পটি কেবলমাত্র পঠন-মোডে ফাইলটি নিজের উপর আবদ্ধ করতে হবে to এটি দুটি পদক্ষেপে করতে হবে:

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

এটি প্রতিটি বুটে করা যেতে হবে, উদাহরণস্বরূপ মাধ্যমে /etc/fstab।

Comments

আমি আশা করি umountফাইলটি যে কেউ আবার লেখার অনুমতি পেতে পারে

— whoan

Answer 8

কেভিনের উত্তরের মন্তব্যে জেরি উল্লেখ করেছেন:

ঠিক আছে, অবশ্যই ফাইলটি নিয়মিত ব্যাক আপ হচ্ছে, আমি কেবল ব্যবহারকারীদের বিরুদ্ধে সুরক্ষার জন্য আরও একটি স্তর চেয়েছিলাম যা কখনও কখনও রুট ব্যবহারকারীর অনুমতি নিয়ে বাক্সে কাজ করে। -

আমি ধরে নিচ্ছি যে আপনি এই অনুশীলনটি পরিবর্তন করতে পারবেন না, কারণ এটি সত্যই, সত্যই খারাপ ধারণা।

কেবলমাত্র পঠনযোগ্য ডিভাইস ব্যবহার সম্পর্কে সমস্ত পরামর্শের একই সমস্যা রয়েছে - এটি আপনার প্রয়োজনের সময় বৈধ পরিবর্তনগুলি করার জন্য এটি পিটা করে তোলে। কোনও লকযোগ্য ড্রাইভের মতো, যেমন একটি এসডি কার্ডের ক্ষেত্রে আপনি এমন সমস্যায় পড়ে যাচ্ছেন যখন আপনি নিজের পরিবর্তনগুলি আনলক করার সময় হঠাৎই দুর্বল হয়ে পড়েছেন।

পরিবর্তে আমি যা সুপারিশ করব তা হ'ল এনএফএস সার্ভার হিসাবে অন্য একটি মেশিন সেট আপ করা, এবং ব্যবহারকারীরা যে রুটগুলি চালু করেছেন সেগুলি মেশিনে গুরুত্বপূর্ণ ফাইলগুলির সাথে ডিরেক্টরিটি ভাগ করে নেবে। মাউন্টটি কেবল পঠনযোগ্য হিসাবে ভাগ করুন, যাতে আপনার বিশ্বাস না করা ব্যবহারকারীদের সাথে মেশিনগুলি কোনও পরিবর্তন করতে না পারে। যখন আপনার আইনীভাবে পরিবর্তনগুলি করা দরকার তখন আপনি এনএফএস সার্ভারের সাথে সংযোগ স্থাপন করতে পারেন এবং সেখানে আমাদের পরিবর্তন করতে পারেন।

আমরা এটি আমাদের ওয়েবসার্সের জন্য ব্যবহার করি, যাতে সার্ভারটি তারপরে যে কোনও ফাইল প্রবেশ করে বা কনফিগারেশনটি পরিবর্তন করতে পারে তা ওয়েবসভারের বিরুদ্ধে সফলভাবে ব্যবহার করা বা সন্নিবেশ করতে বা পরিবর্তন করতে সক্ষম হয় না।

মনে রাখবেন যে মাউন্ট-পয়েন্ট সম্পর্কিত সমস্ত যেমন হতে পারে তেমনভাবে এই স্টুলকে বাইপাস করা যেতে পারে:

• সুরক্ষিত ডিরেক্টরিটির একটি অনুলিপি তৈরি করুন
• ডিরেক্টরিটি আনমাউন্ট করুন
• অনুলিপিটি মাউন্টের জায়গায় সরিয়ে ফেলুন, বা যদি সেই মাউন্টের পর্যাপ্ত জায়গা না থাকে তবে এটিতে সিমিলিং করুন।

Comments

নিয়মিত কোনও গুরুত্বপূর্ণ ফাইল ব্যাকআপ করা এবং দুর্ঘটনাজনিত মোছার বিরুদ্ধে আসলটি রক্ষার চেষ্টা করা কেন "সত্যই, সত্যই খারাপ ধারণা"? ওপির আসল প্রশ্নে এবং আপনি যে উত্তরটি উল্লেখ করেছেন সে সম্পর্কে ওপি'র মন্তব্য থেকে এটি স্পষ্ট যে উদ্বেগ কোনও দূষিত কার্যকলাপ নয়, তবে দুর্ঘটনাক্রমে / অক্ষম কার্যকলাপ।

— ক্রেগ

@ ক্রেইগ: প্রচুর ব্যবহারকারীকে মূল সহকারে রাখা খুব খারাপ ধারণা, বিশেষত যদি তারা সমালোচনামূলক ফাইলগুলিতে গোলমাল না করার জন্য বিশ্বাসী না হয়।

— জো এইচ।

আহ ... অবশ্যই আছে। :-) তবে ওপি-র প্রশ্নের জটলা ছিল না। ওপি দৃ as়ভাবে জানিয়েছিল যে রুট অ্যাক্সেস সহ এমন ব্যবহারকারীরা আছেন যাঁকে দুর্ঘটনাক্রমে কোনও ফাইল মোছার বিরুদ্ধে রক্ষা করা উচিত।

— ক্রেগ

@Craig: এটা প্রশ্ন মূল অংশ নাও হতে পারে, কিন্তু এটা হয় সমস্যা (XY সমস্যা?) মূল অংশ ... কিন্তু আমি কোন ধারণা কি তারা রুট হিসাবে কাজ করছি, তাই যদি তারা setuid ব্যবহার করতে পারে এবং / অথবা সীমিত সুডো সুবিধা। এবং আপনার এই প্রশ্নটি আবার পড়তে হবে, কারণ জেরির দ্বারা আমি উল্লেখ করি না যে তিনি কেবল অনিচ্ছাকৃত অপসারণের বিরুদ্ধে রক্ষা করার চেষ্টা করছেন ("আমার নিশ্চিত হওয়া দরকার এটি যা কিছু মুছে না"), এবং তিনি কেবল একটি ফলোআপ দিয়েছিলেন যে আমি দেখুন (যা আমার প্রতিক্রিয়া জাগিয়ে তোলে)

— জো এইচ।

এই উত্তরের

— ক্রেগ

Answer 9

ডিজাইন দ্বারা কেবল পঠনযোগ্য একটি আইএসও 9660 চিত্র কেন তৈরি করবেন না?

আইএসও চিত্রটি মাউন্ট করুন এবং এটি সিডি-রমের মতো দেখতে লাগবে, তবে হার্ডড্রাইভের পারফরম্যান্সের সাথে এবং মাউন্ট করা চিত্রের ফাইলগুলি কোনও ফিজিকাল সিডি-রোমে থাকা ফাইলগুলির মতো মুছে ফেলা থেকে ঠিক নিরাপদ থাকবে।

সংবেদনশীল ফাইলটি কোনও সিডিতে জ্বালানো এবং এটি একটি সিডি-রম থেকে চালানোর ধারণাটি আকর্ষণীয়, ধরে নেওয়া যে ফাইলটিতে অপরিবর্তনীয় বিটটি সেট করা যথেষ্ট বলে মনে করা হচ্ছে না।

পারফরম্যান্স সহ এটি একটি ফিজিকাল সিডি বন্ধ করে দেওয়ার সম্ভাব্য নেতিবাচক সমস্যা রয়েছে (সিডি-রোম ড্রাইভগুলি অনেক বেশি, হার্ড ড্রাইভ বা এসএসডি এর চেয়ে অনেক ধীর)। সেখানে সিডি-রম কোনও ভাল-অর্থপূর্ণ ব্যক্তি দ্বারা সরানো হবে এবং তাদের যে অ্যাক্সেসের প্রয়োজন হবে এমন একটি আলাদা ডিস্কের সাথে প্রতিস্থাপনের সম্ভাবনা রয়েছে। দূষিত দলের সবেমাত্র ডিস্কটি বের করে মাইক্রোওয়েভে (বা ট্র্যাসে) টস দেওয়ার সম্ভাবনা রয়েছে, এভাবে আপনার ফাইলটি "মুছুন"। কেবলমাত্র একটি ফাইল এবং অন্যান্য কারণগুলির জন্য একটি ডেডিকেটেড হার্ডওয়্যার সিডি-রম ড্রাইভ থাকার অসুবিধা রয়েছে।

তবে ওপি স্পষ্ট জানিয়েছে যে প্রাথমিক অভিপ্রায়টি দুর্ঘটনাজনিত মুছে ফেলার বিরুদ্ধে রক্ষা করা, দূষিত কাজগুলির বিরুদ্ধে নয় এবং প্রশ্নযুক্ত ফাইল (গুলি) ব্যাক আপ করা হয়েছে এবং দুর্ঘটনা ঘটানো উচিত পুনরুদ্ধারযোগ্য, তবে ফাইলটি কখনও কাম্য নয় যে ফাইলটি কখনই না দুর্ঘটনাক্রমে মুছে ফেলা হবে।

মনে হচ্ছে মাউন্ট করা আইএসও চিত্র থেকে ফাইলটি চালানো প্রয়োজনীয়তা পূরণ করবে।

Comments

রুটটি সরাসরি চিত্রটি ম্যানিপুলেট করে কোনও ফাইল মুছতে পারে। এটি কেবলমাত্র একটি সাধারণ ফাইল যা মাউন্ট হবে।

— থরবজর্ন রাভন অ্যান্ডারসন

@ থরবজরন রাভানএন্ডারসেন কীভাবে? নকশা দ্বারা আইএসও 9660 অপরিবর্তনীয়। যে পার্টিটি পরিবর্তন করছে তাতে সম্পূর্ণ আইএসও ফাইল মুছতে এবং প্রতিস্থাপন করতে হবে। তারা যে এটি করতে পারে না তা নয়। তবে তারা প্রবেশ করতে পারল না এবং সার্জিকভাবে এক ফাইলকে অসাধারণ দক্ষতা ছাড়াই মুছে ফেলতে পারে, তবুও। কোনও ড্রাইভ থেকে একটি শারীরিক সিডি-রম সরানো এবং এটি একটি ডাম্পসটারে টস করা আরও সহজ। ;-)

— ক্রেগ

পরিশীলিত হওয়ার দরকার নেই - কেবল জিরো সহ চিত্র ফাইলটি ওভাররাইট করুন।

— থরবজর্ন রাভন অ্যান্ডারসন

@ ThorbjørnRavnAndersen আমি এই বিষয়টিকে সহজেই স্বীকার করব। সাবধানবাণীটি হ'ল এটির জন্য ইচ্ছাকৃতভাবে চিত্রটি খারিজ করা এবং এটি ওভাররাইট করা দরকার। একটি পুঙ্খানুপুঙ্খ অবস্থা ঠিক shredএই মুহুর্তে এটি হবে। তবে আপনি যদি না মেশিনে শারীরিক অ্যাক্সেস অস্বীকার না করেন, তবুও ড্রাইভের বাইরে কোনও ফিজিকাল সিডি পপ করা এবং আইএসপি ফাইলটি বরখাস্ত এবং ওভাররাইটের চেয়ে ডাম্পসেটারে টস করা সহজ, যদিও এটি উভয়ই সহজ। এবং ওপি জানিয়েছে যে গুরুত্বপূর্ণ ফাইলটি নিয়মিতভাবে ব্যাক আপ করা হয়, তাই এটি দুর্ঘটনাকবলিত ক্ষতিগুলির বিরুদ্ধে নয়, দুর্ঘটনাজনিত ক্ষতির বিরুদ্ধে কেবল একটি অতিরিক্ত ব্যবস্থা।

— ক্রেগ

আমি কীভাবে একটি ISO9660 চিত্র পরিবর্তন করতে হবে তা উল্লেখ করেছি এমনকি যদি এটি অপরিবর্তনীয় বলে মনে হয়। আমার বক্তব্যটি হ'ল যদি কিছুটা লিখিত হয় তবে মূলটি এটি লিখতে পারে।

— থরবজর্ন রাভন অ্যান্ডারসন