তৈরি ফাইল এবং ফোল্ডারগুলিতে মালিককে বাধ্য করা

Question

আমার একটি ডিরেক্টরি রয়েছে যা বেশ কয়েকটি ব্যবহারকারীর মধ্যে ডেটা ভাগ করে নিয়েছে। এই ডিরেক্টরিতে অ্যাক্সেস এবং নীচের যে কোনও কিছুই ডিরেক্টরিগুলির গোষ্ঠী দ্বারা নিয়ন্ত্রিত হবে, যা ব্যবহারকারীদের প্রশ্নের সাথে যুক্ত করা হবে। এর মতো আমি ফোল্ডারটি "স্টিকি গ্রুপ" chmod g+sসেট তৈরি করেছি। ডিরেক্টরিটিতে ডিরেক্টরি এবং ফাইল সহ একটি গাছের কাঠামো থাকবে, মোট ফাইলের পরিমাণ কয়েক মিলিয়ন হওয়ার সম্ভাবনা রয়েছে। ফাইলগুলি মোটামুটি ছোট হবে, আমি 50MB এর চেয়ে বড় কিছু প্রত্যাশা করি না।

আমার সমস্যাটি হ'ল ফাইল বা ডিরেক্টরিটির মালিক এখনও এটি তৈরির ব্যবহারকারী। যেমন, আমার যদি সেই ব্যবহারকারীকে অ্যাক্সেস গ্রুপ থেকে অপসারণ করা হয়, আমি তার অ্যাক্সেস পুরোপুরি সরিয়ে ফেলব না।

তাই:

সমস্ত ফাইল এবং উপ-ডিরেক্টরিগুলির একই মালিক রয়েছে তা নিশ্চিত করার জন্য আমি অন্যান্য বিকল্পগুলি কী মিস করেছি?

আমি আশা করি আমি ক্রোন-জব দিয়ে পর্যায়ক্রমে পুরো ডিরেক্টরিটি দিয়ে সার্ফ করতে পারি, তবে এটি আমাকে একবারের পিআর-ফাইল কমান্ডের জন্য অযোগ্য হিসাবে আঘাত করে।

আমি আইএনটিফাই ব্যবহার করে একটি উদাহরণ পেয়েছি তবে এটি আমাকে উচ্চ রক্ষণাবেক্ষণ হিসাবে আঘাত করে, কারণ এতে স্ক্রিপ্টিং দরকার।

এসিএল আমাকে জোর করে মালিকানায় সহায়তা করতে পারে কিনা তা আমি বের করতে সক্ষম হইনি।

এটি করার জন্য আরও দুর্দান্ত উপায় আছে?

আমি যা চাই তা হ'ল একটি ডিরেক্টরি থাকা যা ব্যবহারকারীর সাথে একটি গ্রুপ যুক্ত করে ভাগ করা যায়। এই ডিরেক্টরিতে তৈরি করা যেকোনো কিছুই এর পিতামাতার কাছ থেকে অনুমতি স্কিম উত্তরাধিকার সূত্রে প্রাপ্ত। আমি যে চেষ্টা করছি তার চেয়ে ভাল উপায় যদি থাকে তবে আমি সকলেই কান।

Comments

আপনি আমাকে যা বলতে চাইছেন তা আমি বুঝতে পেরেছি বলে আমি মনে করি না। তুমি কি বিস্তারিত বলতে পারো?

— মার্টিন

একই ফাইল ও মালিকানাধীন সমস্ত ফাইল এবং উপ-ডিরেক্টরিগুলি সেট করার জন্য, কেন ব্যবহার chown -hR owner:groupকরবেন না ?

— পান্ড্যা 10

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

— মার্টিন নীলসেন

কোনও ডিরেক্টরিতে সমস্ত ফোল্ডার / ফাইলগুলির জন্য ডিফল্ট ফাইল অনুমতিগুলি কীভাবে সেট করবেন তার

— প্যাট্রিক

আমি আসলে এই প্রশ্নটি তৈরি করার আগে এই প্রশ্নটি স্কিম করেছিলাম। এটি কোনও নির্দিষ্ট ব্যবহারকারীর কাছে কীভাবে মালিককে বাধ্য করা যায় তা সম্বোধন করার মতো বলে মনে হচ্ছে না।

— মার্টিন নীলসেন

Answer 1

একটি ডিফল্ট মালিক "স্বয়ংক্রিয়ভাবে" সেট করার জন্য এমন একটি ডিরেক্টরি প্রয়োজন যা setuidআচরণ করা হয় setgid। যাইহোক, এটি ফ্রিবিএসডি-তে কনফিগার করা যেতে পারে, অন্যান্য ইউএনআইএক্স এবং লিনাক্স সিস্টেমগুলি এড়িয়ে চলে u+s। আপনার ক্ষেত্রে তবে, আরও একটি সমাধান হতে পারে।

আমি যা চাই তা হ'ল একটি ডিরেক্টরি থাকা যা ব্যবহারকারীর সাথে একটি গ্রুপ যুক্ত করে ভাগ করা যায়। এই ডিরেক্টরিতে তৈরি করা যেকোনো কিছুই এর পিতামাতার কাছ থেকে অনুমতি স্কিম উত্তরাধিকার সূত্রে প্রাপ্ত। আমি যে চেষ্টা করছি তার চেয়ে ভাল উপায় যদি থাকে তবে আমি সকলেই কান।

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

• group_dirডিরেক্টরিটিতে অ্যাক্সেস নিয়ন্ত্রণকারী গ্রুপটি হ'ল ourgroup।
• কেবলমাত্র ourgroupগ্রুপের লোকেরা অ্যাক্সেস করতে পারে group_dir।
• user1এবং user2সম্পর্কিত ourgroup।
• ডিফল্ট উমাস্কটি 0022।

... নিম্নলিখিত সেটআপ বিবেচনা করুন:

drwxrws---    root:ourgroup   |- group_dir/
drwxr-sr-x    user1:ourgroup  |---- group_dir/user1_submission/
drwxr-sr-x    user2:ourgroup  |---- group_dir/user2_submission/
-rw-r--r--    user2:ourgroup  |-------- group_dir/user2_submission/README

^{এখানে, ধরে নেওয়া যাক প্রতিটি আইটেম তার মালিক দ্বারা তৈরি করা হয়েছিল।}

এখন, এই সেটআপে:

• সমস্ত ডিরেক্টরি এতে প্রত্যেককে অবাধে ব্রাউজ করা যায় ourgroup। গ্রুপের যে কোনও ব্যক্তি ভিতরেই যে কোনও জায়গায় ফাইল তৈরি করতে, সরিয়ে নিতে, মুছতে পারে group_dir(তবে আরও গভীর নয়)।
• যে যার মধ্যে নেই ourgroupসেটিকে অবরুদ্ধ করা group_dirহবে এবং অতএব এর অধীনে যে কোনও কিছুই চালনা করতে অক্ষম হবে। উদাহরণস্বরূপ, user3(যিনি এর সদস্য নন ourgroup), পড়তে পারবেন না group_dir/user2_submission/README(যদিও r--ফাইলটিতে তাঁর অনুমতি রয়েছে )।

তবে, এই ক্ষেত্রে কিছুটা সমস্যা আছে: সাধারণ উমাস্কের কারণে, ব্যবহারকারীদের দ্বারা তৈরি আইটেমগুলি গোষ্ঠীর অন্যান্য সদস্যদের দ্বারা চালিত করা যায় না। এসিএলগুলি এখানেই আসে default ডিফল্ট অনুমতি নির্ধারণের মাধ্যমে, আপনি উমাস্কের মান সত্ত্বেও সবকিছু ঠিকঠাক নিশ্চিত করবেন:

$ setfacl -dRm u::rwX,g::rwX,o::0 group_dir/

এই কল সেট:

• rw(x)মালিকের জন্য ডিফল্ট অনুমতি।
• rw(x)গোষ্ঠীর জন্য ডিফল্ট অনুমতি।
• অন্যদের জন্য ডিফল্টরূপে কোনও অনুমতি নেই। মনে রাখবেন যেহেতু অন্যরাgroup_dir যেভাবেই অ্যাক্সেস করতে পারে না , তাই এর অনুমতিগুলির নীচে এটি কী তা বিবেচ্য নয়।

এখন, আমি যদি এই আইটেমটি তৈরি করি তবে user2:

$ touch group_dir/user2_submission/AUTHORS
$ ls -l group_dir/user2_submission/AUTHORS
rw-rw----    user2:ourgroup    group_dir/user2_submission/AUTHORS

এই এসিএলটির জায়গায়, আমরা আমাদের পূর্ববর্তী কাঠামোটি পুনর্নির্মাণের চেষ্টা করতে পারি:

drwxrws---+    root:ourgroup   |- group_dir/
drwxrws---+    user1:ourgroup  |---- group_dir/user1_submission/
drwxrws---+    user2:ourgroup  |---- group_dir/user2_submission/
-rw-rw----+    user2:ourgroup  |-------- group_dir/user2_submission/README

^{এখানে আবার, প্রতিটি আইটেম তার মালিক দ্বারা তৈরি করা হয়।}

অতিরিক্ত হিসাবে আপনি যদি ডিরেক্টরিটি ব্যবহার করছেন তাদের যদি আপনি কিছুটা আরও শক্তি / সুরক্ষা দিতে চান তবে আপনি একটি স্টিকি বিট বিবেচনা করতে পারেন। উদাহরণস্বরূপ, এটি user1মুছে ফেলা থেকে বিরত করবে user2_submission(যেহেতু তার -w-অনুমতি রয়েছে group_dir):

$ chmod +t group_dir/

এখন, যদি ডিরেক্টরিটি user1সরানোর চেষ্টা করে তবে user2সে একটি সুন্দর পাবে Operation not permitted। নোট করুন যেহেতু এটি ডিরেক্টরি কাঠামোগত পরিবর্তনগুলিকে এতে বাধা দেয় তবে এর group_dirনীচে থাকা ফাইল এবং ডিরেক্টরিগুলি এখনও অ্যাক্সেসযোগ্য:

user1@host $ rm -r user2_submission
Operation not permitted

user1@host $ cat /dev/null > user2_submission/README

user1@host $ file user2_submission/README
user2_submission/README: empty (uh-oh)

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

$ chown g= user2_submission/ -R
or
$ chgrp nobody user2_submission -R

... সুতরাং তার পুরো জমা দেওয়ার ডিরেক্টরিটি গ্রুপের কারও কাছে অনুপলব্ধ।

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

Comments

এসিএল কি ডিফল্ট অনুমতিগুলি বাতিল করে দেবে? উদাহরণস্বরূপ, যদি আমি $ setfacl -dRm u :: r, g :: rwX, o :: 0 গ্রুপ_ডির / পরিবর্তে, কেবলমাত্র গ্রুপের সদস্যদের ফাইল তৈরি করার অনুমতি দেওয়ার জন্য, মালিক না থাকলে ফাইলগুলি সম্পাদনা করতে সক্ষম হবেন? দলে? এটি সমালোচনামূলক যে ব্যবহারকারীরা গ্রুপের সদস্য হলেই কেবল ফাইলগুলি সম্পাদনা করতে পারবেন, মালিক কারা তা নির্বিশেষে।

— মার্টিন নীলসেন

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

— জন ডব্লিউ এইচ স্মিথ

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

— মার্টিন নীলসেন

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

— জন ডব্লিউ এইচ স্মিথ

একেবারে না. group_dirডিরেক্টরি মালিকানাধীন হয় root:ourgroupসঙ্গে -rwxr-x---, যার মানে যে শুধুমাত্র root ও সদস্যদের ourgroupএটি হয়তো অ্যাক্সেস, অর্থাত নীচে ফাইল নিয়ে কিছু করতে। আপনি না থাকে তাহলে --xএকটি ডিরেক্টরি অনুমতি, আপনি এটি মধ্যে একটি ফাইল অ্যাক্সেস করতে পারবেন না, এমনকি যদি আপনি ফাইল নিজেই অনুমতি আছে।

— জন ডব্লিউ এইচ স্মিথ

Answer 2

এটি করার একটি দুর্দান্ত উপায় আছে is এটি সেট- গিড এবং ডিফল্ট অ্যাক্সিসের সংমিশ্রণ ব্যবহার করে । স্পষ্টতই, আপনার প্রয়োজন হবে একটি এসিএল সক্ষম ফাইল ফাইল। আসুন ধরে নেওয়া যাক আপনি যে ডিরেক্টরিটি ভাগ করেছেন তা সেখানে রয়েছে /var/grpdirএবং গ্রুপের সদস্যরা sharingএটি অ্যাক্সেস করতে সক্ষম হবেন।

chown root:sharing /var/grpdir
chmod 2770 /var/grpdir #other can't read or traverse into the directory, set-gid is set
setfacl -d -m u::rwX,g::rwX,o::0 /var/grpdir

ডিফল্ট এসিএলগুলি ডিফল্ট এসিএল সহ একটি ডিরেক্টরিতে নির্মিত সাব-ডিরেক্টরি দ্বারা উত্তরাধিকার সূত্রে প্রাপ্ত হয়। সুতরাং এর অর্থ, যে কোনও ফাইল তৈরি করা /var/grpdirহবে এটির sharingডিরেক্টরি সেটগিড বিট দ্বারা সেট করা গ্রুপ থাকবে । অতিরিক্তভাবে, এটি ডিফল্ট অ্যাকসেলগুলির উত্তরাধিকারী হবে, যা ডিফল্ট লিনাক্স শৈলী প্রিমেশনগুলিকে ওভাররাইড করবে, কারণ আমরা নির্দিষ্ট ব্যবহারকারী বা গোষ্ঠীগুলির সাথে এসিএল নির্দিষ্ট করে নি। এর অর্থ সমস্ত ফাইল মালিকানা <user>:sharingএবং অনুমতি নিয়ে তৈরি করা হবে rw-rw----। ডিরেক্টরিগুলি একই হবে, ব্যতীত তাদের নিজস্ব ডিফল্ট এসিএলগুলি তাদের পিতামাতাদের ( /var/grpdir) এর মতো সেট থাকবে এবং অবশ্যই ব্যবহারকারী এবং গোষ্ঠীর জন্য নির্বাহযোগ্য বিট সেট থাকবে। আপনি যদি কোনও sharingগোষ্ঠী থেকে কোনও ব্যবহারকারীকে সরিয়ে থাকেন তবে তারা ডিরেক্টরিতে (এমনকি কোনও ফাইল এতে তাদের মালিকানাধীন) অ্যাক্সেস করতে পারবেন না।

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

Comments

সুতরাং আমি কি এটি সঠিকভাবে বুঝতে পারি: আপনি যদি কোনও ব্যবহারকারী বা গোষ্ঠী নির্দিষ্ট না করেন তবে এসিএলগুলি সাধারণ ফাইল সিস্টেমের অনুমতিগুলি ওভাররাইট করে দেবে?

— মার্টিন নীলসেন

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

— তৈরির

Answer 3

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

বিকল্প:

1. সাম্বা ব্যবহার করুন। সাম্বার force userপ্যারামিটার রয়েছে। আপনি স্থানীয়ভাবে একটি ডিরেক্টরি রফতানি করতে পারেন এবং এটি স্থানীয়ভাবে মাউন্ট করতে পারেন। অ্যাক্সেসগুলি দ্রুত না করে তবে কেবল লুপ ব্যাক নেটওয়ার্কিং জড়িত থাকায় এটি গ্রহণযোগ্য হতে পারে।

2. FAT32 এর মতো একটি নন-লিনাক্স ফাইল সিস্টেম ব্যবহার করুন। এটি অবশ্যই মাউন্ট করার জন্য কোনও নির্দিষ্ট ব্যবহারকারীর জন্য কনফিগার করা উচিত। অ্যাক্সেস অনুমতিগুলি অবশ্যই পিতামাতার ডিরেক্টরি দ্বারা পরিচালনা করা উচিত।

Answer 4

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

সেক্ষেত্রে, আমি মনে করি আপনার সেরা বেটটি ছেঁকা-আর পতাকা সহ ক্রোন কাজ, যেমন পান্ড্য উল্লেখ করেছিলেন mentioned প্রতি মিনিটে বা প্রতি পাঁচ মিনিটে এটি চালানোর জন্য ক্রোনটিতে রাখুন।

আপনার ব্যবহারকারীরা কীভাবে এটি ব্যবহার করছে তা আপনি যদি ব্যাখ্যা করতে পারেন তবে এর থেকে আরও ভাল সমাধান হতে পারে।

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

Answer 5

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

while inotifywait -m -e CREATE web; do echo "A new directory has been created"; done