একবার লিখুন, লিনাক্স ফাইল সিস্টেম ব্যবহার করে অনেকগুলি (WORM) পড়ুন

8

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

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

আমি বুঝতে পারি যে আমি কেবল পঠনযোগ্য অনুমতি এবং অপরিবর্তনীয় বৈশিষ্ট্য সেট করতে পারি। তবে অবশ্যই আমি প্রত্যাশা করি যে কোনও রুট ব্যবহারকারী সেগুলি আনসেট করতে সক্ষম হবেন।

আমি ছোট ভলিউমগুলিতে ডেটা সঞ্চয় করার বিষয়টি বিবেচনা করেছি যা আনমাউন্ট হয় এবং তারপরে কেবল পঠনযোগ্য পুনরায় সঞ্চারিত হয় তবে আমি মনে করি যে রুটটি এখনও লিখিতযোগ্য হিসাবে আনমাউন্ট এবং পুনঃনির্মাণ করতে পারে।

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

এত কিছুর পরে, ফাইলগুলিতে এনক্রিপশনও কার্যকর হবে!

— phil_ayres
সূত্র

4

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

— Regan

এসইসি ব্যাখ্যার পরে Sec.gov/rules/interp/34-47806.htm আমি @ রেজানের সাথে একমত হতে চলেছি। যাইহোক, এই পুরো জিনিসটি কিছুটা অযৌক্তিক। উদাহরণস্বরূপ, কিভাবে একটি সিডি মুছে যায়? অবশ্যই আগুনের সাথে।

— মার্ক ওয়াগনার 23

আমি সম্পূর্ণরূপে সম্মত হই যে প্রয়োজনীয়তাগুলি 'সামান্য অযৌক্তিক'। তারা এটিকে এতটা সুস্পষ্ট করার চেষ্টা করছে যে সত্যকে আড়াল করার চেষ্টা করা হয়েছে যে কোনও আইটি লোক কোনও ভাল-অভিনেতাকে যা করতে বলছে তা করতে রাজি হবে না। রুট হিসাবে একটি বৃহত ডিরেক্টরিতে মুছুন হিট করা কারও পক্ষে দৃশ্যত খুব সহজ ছিল। শারীরিক ধ্বংসগুলি এসইসির নিয়মগুলিতে জিনিসগুলি coverাকানোর একমাত্র উপায় হয়ে যায়।

— ফিল_ইরেস

chattr + i ফাইলের নাম, আপনি প্রত্যেকবার ফাইল তৈরি করার সময় এই কমান্ডটি দেওয়া দরকার

— c4f4t0r

@ c4f4t0r থামছে না: chattr -i filenameতারপরে rm

— phil_ayres

2

আপনি এটিকে ওপেনএএফএস এবং কেবল পঠনযোগ্য খণ্ডের সাথে সাজিয়ে নিতে পারেন। এটিকে কাজ করার জন্য এটি প্রয়োজনীয় অনেকগুলি অবকাঠামো এবং প্রয়োজনীয়তা পূরণ করতে পারে না।

http://www.openafs.org/

মূলত, এখানে লেখার যোগ্য ভলিউম এবং ভলিউমের এক বা একাধিক পঠনযোগ্য অনুলিপি রয়েছে। আপনি লেখার যোগ্য ভলিউম প্রকাশ না করা পর্যন্ত কেবল পঠনযোগ্য অনুলিপি ক্লায়েন্টদের কাছে অপরিবর্তনীয়। ভলিউম প্রকাশের জন্য প্রশাসকের সুবিধাগুলি প্রয়োজন requires

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

— ফ্রেড ম্যাজিক ওয়ান্ডার কুকুর
সূত্র

ওপেনএফএফএস কি কেবল পঠনযোগ্য ভলিউমে লিখতে বাধা দেয় না। আমি ডক্সে একটি নির্দিষ্ট সংজ্ঞা পাইনি।

— ফিল_ইরেস

এটি অবশ্যই গ্রাহকের রু ভলিউমগুলিতে লিখতে বাধা দেয়। সাধারণত রুট ওপেনএফএএস-তে কোনও বিশেষ অনুমতি বোঝায় না।

— ফ্রেড দ্য ম্যাজিক ওয়ান্ডার ডগ

1

দেখে মনে হচ্ছে কাস্টম ফাইল সিস্টেম / কার্নেল কোড না লিখে এটি করার কোনও উপায় নেই।

একটি কার্যকর সমাধান হ'ল বিশ্বব্যাপী সংরক্ষণাগার স্টোরেজ বিকল্পের সাথে অ্যামাজন হিমবাহ ব্যবহার করা হবে। এডাব্লুএস অফিসিয়াল ব্লগ অনুযায়ী: https://aws.amazon.com/blogs/aws/glacier-vault-lock/

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

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

আমার জন্য, এটি রেকর্ড ধরে রাখার প্রয়োজনীয়তাগুলি পূরণ করার জন্য, নেট অ্যাপ বা ইএমসি হার্ডওয়্যার ব্যয় ছাড়াই যা প্রয়োজন তা হুবহু উপলব্ধ করে।

— phil_ayres
সূত্র

আমার সমাধান থেকে কোন যুক্তির পার্থক্য নেই। সার্ভার প্রশাসক, এক্ষেত্রে অ্যামাজন এখনও কিছু বা সমস্ত ফাইল মুছতে বা টেম্পার করতে পারে। এখানে পার্থক্য কেবল ফাইল স্টোরেজ প্রদানকারী ...?

— এনআরসি

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

— phil_ayres

1

আপনি এখনও স্টোরেজের জন্য অর্থ প্রদান বন্ধ করে ফাইলগুলি মুছতে পারেন।

— টমাস জুবিরি

0

আপনার যদি কেবল এমন কোনও সিস্টেম থেকে ফাইলগুলি অ্যাক্সেসের প্রয়োজন হয় যেখানে ব্যবহারকারীরা সেগুলি ওভাররাইট করতে পারে না তবে আপনি কোনও রিমোট ভলিউম মাউন্ট করতে পারেন যার উপর আপনার লেখার অনুমতি নেই। এটি করার সবচেয়ে সহজ উপায় হ'ল কেবলমাত্র পঠিত সাম্বা / সিআইএফ ভাগ ভাগ করে নেওয়া।

অন্যথায় আপনার যদি ব্যবহারকারীদের নতুন ফাইল লেখার মঞ্জুরি দেওয়ার উপায়ের প্রয়োজন হয় (এটি ওভাররাইট বা সংশোধন করা যায় না) একটি সমাধান হ'ল FUSE কারফল্টপিএফসের সাথে একটি এফটিপি পাথ মাউন্ট করা।

আপনি এই নির্দেশাবলী সঙ্গে আপনার proftpd ডিরেক্টরি সেট করতে পারেন:

AllowOverwrite off
<Limit WRITE>
  DenyAll
</Limit>
<Limit STOR>
  AllowAll
</Limit>

এইভাবে নতুন ফাইলগুলি মাউন্টড ডিরেক্টরিতে সংরক্ষণ করা যেতে পারে, তবে সেগুলি আর পরিবর্তন বা সরানো যাবে না।

লিঙ্ক: CurlFtpFS , ProFTPD

— NRC
সূত্র

আপনি যা বলছেন তা আমি পেয়েছি এবং এটি অবশ্যই একটি বিকল্প বলে মনে হচ্ছে। তবে আমি যদি ফাইল সার্ভারের প্রশাসক হন তবে আমি কিছু মুছতে পারি। লক্ষ্যটি হ'ল এমনকি প্রশাসকদের (কমপক্ষে শারীরিক ড্রাইভে অ্যাক্সেসবিহীন) ফাইল মুছে ফেলা থেকে বিরত রাখা।

— ফিল_ইরেস

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

— এনআরসি

দুর্ভাগ্যক্রমে কেবল এসইসি রেজিস্ট্রেশন অনুসারে টেম্পারিংয়ের প্রদর্শন করার জন্য ফাইল সাইন ইন করা অপর্যাপ্ত। সুতরাং ফাইলগুলি সম্পূর্ণরূপে অপরিবর্তনীয় করার বিষয়ে প্রশ্ন।

— ফিল_এরেস

0

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

প্ল্যান 9 বা এর ডেরিভেটিভসগুলি প্রয়োজনীয় সমস্ত বৈশিষ্ট্যগুলিকে অন্তর্ভুক্ত করতে পারে। দেখুন Plan9 এবং Venti

— ড্যানিয়েল ম্যাথিউজ
সূত্র