অনুমতিগুলির উদ্দেশ্য যেমন 0111 বা 0333

Question

111 বা 333 এর মতো লিনাক্স অনুমতিগুলির উদ্দেশ্য কী (যেমন ব্যবহারকারী ব্যবহারকারী কার্যকর করতে পারে তবে ফাইলটি পড়তে পারে না ), যদি কার্যকর করার ক্ষমতাটি স্বয়ংক্রিয়ভাবে পড়ার ক্ষমতা বোঝায় না?

Comments

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

— ইকরাব

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

— বার্ড কোপ্পেরুদ

Answer 1

আমি এটি নিয়ে খেলেছি এবং দৃশ্যত, এক্সিকিউটিভ অনুমতিগুলি পড়ার অনুমতি বোঝায় না। বাইনারিগুলি পাঠযোগ্য না হয়ে কার্যকর হতে পারে:

$ echo 'int main(){ puts("hello world"); }' > hw.c
$ make hw
$ ./hw
hello world
$ chmod 111 hw
$ ./hw 
hello world
$ cat hw
/bin/cat: hw: Permission denied

যদিও স্ক্রিপ্টগুলি কার্যকর করতে পারি না, যদি না তাদের উভয়ই অনুমতি বিট পড়ে এবং চালায়:

$ cat > hw.sh
#!/bin/bash
echo hello world from bash
^D
$ chmod +x ./hw.sh
$ ./hw.sh 
hello world from bash
$ chmod 111 ./hw.sh
$ ./hw.sh
/bin/bash: ./hw.sh: Permission denied

Comments

এটি সঠিক যেমন দ্বিতীয় উদাহরণটি # ব্যবহার করে! এটি ইএলএফ-শিরোনামটিকে মিস না করায় আরম্ভ করতে এবং ফাইলটি এটি ব্যবহারের জন্য কার্যকর হতে পারে তা অনুমান করার জন্য এটি পঠনযোগ্য হতে হবে। এটি এমন একটি সাধারণ পরিস্থিতি যেখানে আপনি ফাইলগুলির বিষয়বস্তুগুলি অন্য স্থানে অনুলিপি করা থেকে রক্ষা করতে চান। লাইসেন্স ম্যানেজার সাধারণ উদাহরণ যেখানে আপনি এটি দেখতে পাবেন see

— hspaans

নোট করুন যে আপনি এখনও কার্যকর হতে পারে কেবল বাইনারি পড়তে পারেন: unix.stackexchange.com/a/34294

— 太郎 太郎

@hspaans: শেবাং কর্নেল দ্বারা পরিচালিত হয়, এবং কার্নেল অনুমতিগুলির মতো অদ্ভুত ছোট ছোট জিনিসগুলির যত্ন করে না। এটি শেল (বা দোভাষী) যা পড়ার অ্যাক্সেস প্রয়োজন। কার্নেল চালায় (বলুন) /bin/bash hw.sh, এবং তারপরে বাশ hw.shপড়ার জন্য খোলার চেষ্টা করে (এবং ব্যর্থ হয়)।

— কেভিন

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

— এমিল জেবেক মনিকা 24

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

— বার্মার

Answer 2

এটি ডিরেক্টরিগুলির জন্য অর্থবহ করে তোলে, উদাহরণস্বরূপ আপনি যদি কোনও নির্দিষ্ট ডিরেক্টরিতে (গোপন) এক্সিকিউটেবল রাখেন এবং তারপরে ব্যবহারকারীরা ডিরেক্টরি বিষয়বস্তু দেখতে না পেয়ে সেই ফাইলগুলিকে কল করার অনুমতি দেন (তবে আপনি তাদের অবহিত করার পরে একটি নির্দিষ্ট ফাইল রয়েছে তা জেনে!) 111 এর তুলনায় 333 ডিরেক্টরিগুলির বিষয়বস্তু দেখতে সক্ষম না হয়ে সেই ডিরেক্টরিতে / থেকে ফাইলগুলি লিখতে / মুছতে সক্ষম করে।

Comments

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

— ডার্কহার্ট

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

— পিএসকোকিক

Answer 3

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

তাহলে ব্যবহারকারীগণকে read-পরিমিতি (এবং কেবলমাত্র execute-প্রেমিসন) দিচ্ছেন না কেন ? এমন একটি ফাইল বেক করুন যা কোনও ব্যবহারকারী দ্বারা পঠনযোগ্য নয়, সেই ব্যবহারকারী দ্বারা অনুলিপি করা যাবে না ! readঅনুমতি অপসারণ , ব্যবহারকারীদের তাদের নিজস্ব "ব্যক্তিগত" এক্সিকিউটেবলের অনুলিপিগুলি তৈরি করতে বাধা দেয় - যা তারা পরে অপব্যবহার করতে সক্ষম হতে পারে (উদাহরণস্বরূপ প্রাপ্ত SUID=root on) get

এবং write-বিহীনতা না থাকা , একটি ফাইল তাত্ক্ষণিকভাবে মোছা থেকে বাধা দেয়।

মনে মনে, মালিককে readদু'টিও write-অনেক- বিশেষায়িত না দেওয়া কিছুটা অস্বাভাবিক, তবে কখনও কখনও ownerকেবল কোনও ফাইল মুছে ফেলা থেকে বিরত রাখা ভাল ধারণা হতে পারে । অবশ্যই owner- উল্লেখ না করা root- সর্বদা এই জাতীয় পদক্ষেপগুলি নষ্ট করে দিতে পারে, যদি অন্য উপায়ে না হয়, তবে কেবলমাত্র chmodফাইলের অনুমতি দ্বারা ।

Comments

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

— সেলেদা

কেবলমাত্র প্রস্তুত এক্সিকিউটেবলগুলি ব্যবহার করা যেতে পারে উদাহরণস্বরূপ যদি এক্সিকিউটেবল কোনও ডেটাবেস পাসওয়ার্ড এম্বেড করে যা এটি কোনও ডেটাবেসে সংযুক্ত হওয়ার জন্য এবং এর কাজটি চালানোর জন্য ব্যবহার করে তবে এটি পাসওয়ার্ডটি প্রকাশ করার প্রয়োজন হয় না।

— সেলেদা

@ ক্যালাডা, এটি একটি পুরানো প্রশ্ন, তবে মেমরি অঞ্চলটি অফসেটগুলি খুঁজে বের করে /proc/${PID}/mapsএবং তারপরে স্মৃতি সম্পর্কিত বিভাগগুলি পড়ার মাধ্যমে মেমরি ডাম্পিংয়ের ক্ষেত্রে এমন দৃষ্টিভঙ্গি হতে পারে না /proc/${PID}/mem? বা এক্সিকিউটেবলের ফাইলটিতে অনুমতিগুলি সীমাবদ্ধ করে মৃত্যুদণ্ড কার্যকর করার সময় স্মৃতিতে তার সম্পর্কিত বিভাগগুলিতে পড়া অনুমতিগুলিও সীমাবদ্ধ করে? (পরেরটি অসম্ভব বলে মনে হচ্ছে, আইএমও।)

— স্পেন্সার