আমি কি এক্সট্রা ৪ এক্সটার্নাল হার্ড ড্রাইভের জন্য কম্পিউটারের ব্যবহারকারীর অনুমতিগুলি পোর্ট করতে পারি?


16

আমার কাছে একটি বাহ্যিক ইউএসবি 3 ডিস্ক ড্রাইভ (2 টিবি ক্ষমতা) রয়েছে যা সম্ভবত মেশিন থেকে মেশিনে স্থানান্তরিত হতে চলেছে। ডিস্কটিতে একটি জিইউইডি পার্টিশন টেবিল এবং একটি এক্সট 4 পার্টিশন রয়েছে। আমি প্রক্রিয়াটি উন্নত না করে আমি ডিস্কে লিখতে অক্ষম ( sudo)।

এখন পর্যন্ত আমি নিম্নলিখিতগুলির একটি বা উভয় চেষ্টা করার কথা ভাবছি এবং প্রতিটিটির কনসটি জানতে চাই -

  1. chmod 777 /mnt/externalDrive
  2. chown nobody:nogroup /mnt/externalDrive

আমি যদি 777 অনুমতি দিই এবং ব্যবহারকারী 1 (ইউআইডি: 1005) এটি লিখে এবং আমি পরে ডিস্কটিকে অন্য একটি কম্পিউটারে স্থানান্তর করি যেখানে ইউজার 7 ইউআইডি: 1005 হয়, তখন কী ঘটে? ব্যবহারকারী 7 কি সেই কম্পিউটারে ফাইলটির মালিক হয়ে যায়? আমার কাছে মনে হয় আমাকে পর্যায়ক্রমে chown -R nobody:nogroup /mnt/externalDriveডিস্কে চালাতে হবে।

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


আমি আপনাকে অনুসরণ করি কিনা তা নিশ্চিত নই। আপনি কি বাহ্যিক ড্রাইভে অনুমতিগুলি সেট করার চেষ্টা করেছিলেন?
রমেশ

1
হ্যাঁ. এটা কি একটি ভাল জিনিস?
লর্ড লোহ

উত্তর:


19

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

  • আপনি আপনার বাহ্যিক ড্রাইভটি ব্যবহার করছেন এমন প্রতিটি মেশিনে আপনার অ্যাকাউন্টের জন্য একই ইউআইডি থাকা (প্রকৃত পক্ষে সম্ভব নয়, কারণ সম্ভবত সমস্ত মেশিনই আপনার নিয়ন্ত্রণে নেই)
  • মালিক / গোষ্ঠী সংযোগ সম্পর্কে অজানা একটি ফাইল-সিস্টেম ব্যবহার করা (FAT বা এনটিএফএস মাথায় আসে, তবে… আআআহ, না)

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

  1. এই গ্রুপের মালিকানাধীন আপনার ড্রাইভে সমস্ত ফাইল এবং ডিরেক্টরি তৈরি করুন
  2. কোনওভাবে সেই ফাইলগুলি এবং ডিরেক্টরিগুলিতে উপযুক্ত গোষ্ঠী-অনুমতি থাকতে পরিচালনা করুন
  3. কোনওভাবে উপযুক্ত গ্রুপ-মালিকানা সহকারে নতুন ফাইল তৈরি করতে পরিচালনা করুন। অনুমতি।

প্রথম এবং দ্বিতীয় পয়েন্টটি ( chown, chmod) সম্পাদন করা সহজ । তৃতীয় পয়েন্টটি কিছুটা কৌশলযুক্ত।

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

অনুমতি বিটটি কিছুটা শক্ত। সদ্য নির্মিত ফাইল / ডিরেক্টরিগুলির অনুমতিগুলি (অন্যদের মধ্যে) এর দ্বারা প্রভাবিত হয় umask, একটি বিট-মাস্ক বলছে যে কোন বিটগুলি স্পষ্টভাবে বর্ণিত না হলে সেট না করা। umaskউদাহরণস্বরূপ একটি সাধারণ মান 022, যার অর্থ »গোষ্ঠী« এবং »অন্যদের for রাইটিং-বিটগুলি সাধারণত সেট করা উচিত নয়। আপনি এতে পরিবর্তন করতে umaskপারেন 002, আপনাকে লিখিত অনুমতিগুলি গোষ্ঠীর জন্য সাফ করতে চান না তবে ক্ষুদ্রতর দিকটি হ'ল আপনি এই মান ডিরেক্টরিটি-ভিত্তিক সেট করতে পারবেন না এবং আপনি সাধারণত লেখার অনুমতি নিতে চান না আপনার তৈরি প্রতিটি ফাইলের জন্য আপনার প্রাথমিক গ্রুপ সেট।

এটি এসিএলগুলি ব্যবহার করে সমাধান করা যেতে পারে: একটি এসিএলে আপনি একটি maskএবং একটি defaultঅনুমতি সেট সেট করতে পারেন যা এই এসিএল সেটটি দিয়ে একটি ডিরেক্টরিতে তৈরি সমস্ত ফাইল এবং ডিরেক্টরিগুলির ক্ষেত্রে প্রযোজ্য। সুতরাং আপনার সমস্যার সম্ভাব্য সমাধান হ'ল

  • আপনি আপনার বাহ্যিক ড্রাইভটি চালু করতে চান এমন সমস্ত সিস্টেমে আপনি একটি সাধারণ গ্রুপের সদস্য কিনা তা নিশ্চিত করে
  • এই গ্রুপের মালিকানাধীন আপনার ড্রাইভে সমস্ত ফাইল এবং ডিরেক্টরি তৈরি করুন এবং সমস্ত ডিরেক্টরিতে এসজিআইডি বিট সেট করুন
  • একটি মাস্ক এবং ডিফল্ট অনুমতি অন্তর্ভুক্ত করতে সমস্ত ডিরেক্টরিগুলির এসিএল পরিবর্তন করুন যা কার্নেলকে গ্রুপের জন্য লেখার অনুমতি সহ প্রতিটি নতুন ফাইল / ডিরেক্টরি তৈরি করতে বলে।

দেখুন setfacl(1), এবং acl(5)আরও বিশদ জন্য।


1
এক্সট 4 , স্পিনিকস.এন.লিস্ট / লিনিক্স / লিনিক্স-fsdevel / msg57240.html তে তাঁর এবং গিড ম্যাপিংয়ের জন্য চারপাশে একটি প্যাচ ভাসছিল , তবে আমি মনে করি না এটি হয়েছে ...
রুমানো

11

আছে অন্য অনুরূপ প্রশ্ন এবং bindfs সেখানে পরামর্শ দেওয়া হয়:

mkdir /home/$user/sda1
bindfs -u $user -g $group /mnt/sda1 /home/$user/sda1

ওএসএক্স ব্যবহারকারীরা noownersমাউন্ট বিকল্পটিকে এভাবে বর্ণিত পরামর্শ দেয় :

সম্পূর্ণ ভলিউমের জন্য মালিকানা ক্ষেত্রটি উপেক্ষা করুন। এটি সমস্ত আইডিকে ব্যবহারকারীর আইডি 99 এবং গ্রুপ আইডি 99 এর মালিকানা হিসাবে উপস্থিত হতে পারে। ব্যবহারকারী আইডি 99 কে বর্তমান কার্যকর ব্যবহারকারী আইডি হিসাবে ব্যাখ্যা করা হয়, যখন গ্রুপ আইডি 99 সরাসরি ব্যবহৃত হয় এবং `` অজানা 'অনুবাদ করে।


bindfs বেশ ধীর। সম্ভবত এটি একটি FUSE ফাইল সিস্টেম because
নবীন

4

কোনও ফাইলের মালিক এবং গোষ্ঠী সংখ্যা হিসাবে সংরক্ষণ করা হয়। সুতরাং ফাইলটি ইউআইডি = 1005 এর মালিকানাধীন হবে, সিস্টেমটিতে যার সাথে সংযুক্ত রয়েছে সেটিকে নির্বিশেষে কোনও ব্যবহারকারী (বা মোটেও কিছুই নয়)।

কারও কাছে ব্যবহারকারী / গোষ্ঠী পরিবর্তন করা আপনার সমস্যার সমাধান করবে না। তারপরে কেবলমাত্র কেউ নেই (বা কেউ নয় গ্রুপের সদস্যদের) ফাইলগুলিতে অ্যাক্সেসের অনুমতি দেওয়া হবে।

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


2

আন্ড্রেস উইস বলেছে যে আপনার কাছে সমস্ত হোস্ট জুড়ে অভিন্ন গ্রুপ আইডি থাকলে আপনি setgidবিট এবং এসিএল দিয়ে আপনার সমস্যাটি সমাধান করতে পারেন

আমি লিনাক্স ডিস্ট্রোস জুড়ে পূর্বনির্ধারিত গোষ্ঠী আইডিস প্রশ্ন করি ?

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

এর সাথে:

$ sudo chgrp -R sys /mnt/data/dir
$ sudo chmod -R g+s /mnt/data/dir
$ sudo setfacl -R -m g:sys:rwx /mnt/data/dir
$ sudo setfacl -R -d -m g:sys:rwx /mnt/data/dir

এবং এর স্বাদ:

$ sudo adduser user sys

আপনি userকোনও ফাইল পড়তে / লিখতে সক্ষম হবেন /dir

বেশিরভাগ কাজ setgidকিছুটা হলেও করতে পারে তবে দুর্ভাগ্যক্রমে আপনার সাধারণত নিয়ন্ত্রণ খুব কম থাকে umask। সুতরাং ACL সম্পূর্ণ সমাধান সরবরাহ করতে ব্যবহৃত হয়।

আরো দেখুন:

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.