ডিরেক্টরিতে সেটিউডকে কেন উপেক্ষা করা হয়?

Question

লিনাক্স সিস্টেমে আপনি সফলভাবে করতে পারবেন chmod u+s $some_directory, তবে নতুন ডিরেক্টরি উপস্থাপনা এবং ফাইলগুলি মালিকানাধীন ডিরেক্টরিটির (এবং u+sপাশাপাশি সাবডাইরেক্টরিও সেট করার ) মালিক হিসাবে বাধ্য করার পরিবর্তে সিস্টেমটি সেটআপ বিটটিকে উপেক্ষা করবে। সাব ডিরেক্টরি এবং ফাইলগুলি তাদের তৈরি প্রক্রিয়াগুলির ইউআইডি উত্তরাধিকার সূত্রে চালিয়ে যায় এবং সাব-ডিরেক্টরিগুলি ডিফল্টরূপে সেট করা হয় না।

ডিরেক্টরিগুলিতে সেটুয়েডকে কেন উপেক্ষা করা হয় এবং আমি কীভাবে এটির সিস্টেমটি সনাক্ত করতে পারি?

Comments

আমি ভাবছি "নসুইড" মাউন্ট বিকল্পটি এটিকে প্রভাবিত করতে পারে কিনা।

— হেপাটাইতে

প্রশ্নের মধ্যে থাকা ফাইল সিস্টেমটি মাউন্ট করা হয়নি nosuid— যদিও অন্য একটি আছে (একটি র‌্যামডিস্ক, /dev/shm) যা / রয়েছে / মাউন্ট করা হয়েছে nosuidএবং এটি setuidবিটটিকে ঠিক একইভাবে আচরণ করবে বলে মনে হচ্ছে । 6_9

— ব্ল্যাকলাইট জ্বলজ্বল

আরও দেখুন: সার্ভারফল্ট.কোয়েশনস

— জাজলিন

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

— মাইকব্যাকক

Answer 1

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

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

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

Comments

আমি এটি বাস্তবায়িত করতে চাই, যদি কেবল ধারাবাহিকতার জন্যই হয় ... এক্স 3 কোনও অবস্থাতেই ক্রোনজব এর মতো কাজকর্মের সংক্ষিপ্ততা পর্যায়ক্রমে চলে যেতে এবং মালিকানা পরিবর্তন করতে, / ফাইলের মালিকানা বাধ্য করার কোনও উপায় আছে কি?

— ব্ল্যাকলাইট জ্বলজ্বল

আমি বোকা ধারাবাহিকতায় এমারসনকে উদ্ধৃত করতে প্রলুব্ধ হই। আপনি আমাকে বোঝানোর আগে এটি একটি পছন্দসই বৈশিষ্ট্য, আপনি আমাকে ব্যবহারের কেসটি প্রদর্শন করতে হবে যেখানে এটি অর্থবোধ করে।

— আইজাক রবিনোভিচ

ফ্রিবিএসডি chmod (2) এর আসলে এটি নিয়ে কিছুটা আলোচনা রয়েছে তবে কেবল উল্লেখ করেছেন যে এটি অনির্দিষ্ট "সুরক্ষা গর্তগুলির" কারণে সাধারণত ব্যবহার করা উচিত নয়। আমি সন্দেহ কারণ যখন এটি কিছু ব্যবহারের ক্ষেত্রে আছে, এটা না অন্যান্য অধিকাংশ Unixes এই বৈশিষ্ট্যটি দত্তক গ্রহণ করা হয়নি যে ভয়ঙ্কর দরকারী।

— jjlin

"হোম ডিরেক্টরিতে সেট করা" এর ইউটিলিটিটি দেখতে শক্ত ", সুতরাং মূল হিসাবে চলমান বিধান স্ক্রিপ্টগুলি দুর্ঘটনার কারণে কোনও কিছু ছুঁতে ভুলতে পারে না?

— ufotds

আপনার বাড়ির ডিরেক্টরিতে সুপারসার স্ক্রিপ্ট চালানো সত্যিই খারাপ ধারণা

— আইজাক রবিনোভিচ

Answer 2

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

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

আচরণ পরিবর্তন করার জন্য আপনাকে ওএস লাইব্রেরি এবং ইউটিলিটিগুলি সংশোধন করতে হবে।

Answer 3

এটি বাস্তবায়নের জন্য একটি খুব ভাল ব্যবহারের কেস হ'ল:

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

যদি ডিরেক্টরিগুলির অনুমতিগুলির জন্য সেটগাইড কিন্তু সেটগিড বিটের মতো কাজ করে তবে এটির মতো দেখতে হবে:

/var/www/sitea - apache:groupa  rwS rwS ---
/var/www/siteb - apache:groupb  rwS rwS ---
/var/www/sitec - apache:groupc  rwS rwS ---

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

অপর ব্যবহারের ক্ষেত্রে বেনামে ftp / http বা এমনকি sftp / ssh আপলোড। আপলোড ডিরেক্টরিতে থাকা গ্রুপ এবং জিআইডি রুট হবে এবং তাই মালিক এবং ইউআইডি। অন্যান্য অনুমতি হবে -wx। এটি প্রত্যেককে আপলোড ডিরেক্টরিটিতে WRITE অ্যাক্সেসের অনুমতি দেবে কিন্তু এটি আপলোড হওয়ার পরে তারা কিছুই পড়তে পারেনি এবং নতুনভাবে তৈরি হওয়া সমস্ত ফাইলের মূল রুটের মালিক হবে।

সুতরাং জিআইডি বিটের সাথে মিল রাখতে ডিরেক্টরিগুলিতে ইউআইডি কার্যকারিতা সক্ষম করার জন্য দুটি নিখুঁত ভাল এবং বৈধ ব্যবহারের কেস রয়েছে।

স্টিভেন মার্কুরিও

Comments

এটি যে প্রশ্নটি জিজ্ঞাসা করেছিল তার ঠিকানা বলে মনে হচ্ছে না।

— কেভিন পানকো

@ কেভিনপ্যাঙ্কো না, এটি আমার প্রশ্নের উত্তর দেয় না। এমনকি এটি সাইটের জন্য অফ-টপিকও হতে পারে ("এর ব্যবহারের ক্ষেত্রে কী কী <nonexistent feature X>?")। তবে এটি আমার প্রশ্নের সাথে সম্পর্কিত এবং আমি জিজ্ঞাসাবাদক হিসাবে এটি দরকারী বলে মনে করি।

— ব্ল্যাকলাইট

Answer 4

পার্টিতে কিছুটা দেরি হয়ে গেছে, তবে ভবিষ্যতে পাঠকরা যদি এইজন্য হোঁচট খায়;) অন্যদের বক্তব্য অনুসারে, একটি স্ট্যান্ডার্ড ওএস-এক্স ফাইল সিস্টেমে ডিরেক্টরিগুলির জন্য সেটইউইউডিটি উপেক্ষা করা হয় - এবং এর কাছাকাছি কোনও সহজ উপায় বলে মনে হয় না ( mount -o.... বা কি না)। প্রায়শই, ম্যান পেজটি আসলে ওএস-এক্স আচরণের সাথে আক্ষরিকভাবে মেনে চলে না:

4000 (সেট-ইউজার-আইডি-অন-এক্সিকিউশন বিট) [...] সেট-ব্যবহারকারী-আইডি বিট সেট সহ ডিরেক্টরিগুলি তাদের মধ্যে তৈরি সমস্ত ফাইল এবং উপ-ডিরেক্টরিগুলি ডিরেক্টরি মালিকের মালিকানাধীন হতে বাধ্য করবে এবং দ্বারা নয় তৈরি প্রক্রিয়া uid [...]

তবে এটি মূল মালিকানা ছেড়ে না দিয়ে একই প্রভাব অর্জনের সম্ভাবনার তালিকাও দেয়। লিনাক্স একই ধরণের প্রভাবের জন্য '[g /] সেটফ্যাকলস' ব্যবহার করে (তারা প্রথম নজরে সত্যই দৃশ্যমান নয়, তাই এটি কখনও কখনও উপদ্রব হতে পারে)।

'আমি কীভাবে একইরকম প্রভাব অর্জন করতে পারি' হিসাবে পুরো ম্যান পৃষ্ঠাটি পড়ুন এবং এর সাথে ফ্রেড:

chmod +a 'guest allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' ./[DIRECTORY]

আপনি মাধ্যমে পরীক্ষা করতে পারেন

ls -le

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

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

chmod +a 'mygroup allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' /fileserver/groupfolders/mygroup

Comments

স্ট্যাক এক্সচেঞ্জে স্বাগতম! এটি একটি উত্তরের উত্তর, যদিও এটি লিনাক্স ডিস্ট্রোসের পরিবর্তে ওএস এক্সের সাথে সম্পর্কিত (যা আপনি উল্লেখ করেছেন, একটি ভিন্ন এসিএল সিস্টেম ব্যবহার করুন), এটি এখানে তেমন প্রাসঙ্গিক বলে মনে হয় না। ওএস এক্স সম্মান নির্ধারিত ডিরেক্টরিগুলি কীভাবে তৈরি করবেন সে সম্পর্কে একটি প্রশ্নে এটি অবশ্যই ভাল ফিট হবে ; আপনি একটি পোস্ট করা উচিত ?

— ব্ল্যাকলাইট জ্বলজ্বলে

যাইহোক, ওএস এক্স এর ম্যানুয়াল পৃষ্ঠা থেকে আপনি যে বিটটি রেখে গেছেন তা chownবেশ গুরুত্বপূর্ণ মনে হচ্ছে! "[…] যদি অন্তর্নিহিত ফাইল সিস্টেমটি এই বৈশিষ্ট্যটিকে সমর্থন করে: chmod (2) এবং মাউন্ট (8) এর জন্য suiddir বিকল্পটি দেখুন” "আমি আসলে এর আগে কিছুটা আগে লক্ষ্য করিনি। যদি এইচএফএস প্রয়োগ করে তবে suiddirআপনি এটি একটি সাধারণ ওএস এক্স সিস্টেমে বাস্তবে ঘটতে পারেন।

— ব্ল্যাকলাইট জ্বলজ্বলে

(এবং লিনাক্স এসিএলগুলি ওএস এক্স এসিএলগুলি ঠিক ততটাই "প্রথম নজরে দৃশ্যমান নয়"

— ব্ল্যাকলাইট শাইনিং

Answer 5

ভাল, এটি মান সম্মান করা উচিত। আমি এসএফটিপি-কেবলমাত্র বেশ কয়েকটি দৃশ্যের সাথে ভাবতে পারি যে এটি এসিএস এবং এসএইচডি যে এসিএল-মাস্ক-সেট উভয়ই আমাকে অনেক সমস্যা বাঁচাতে পারে এবং আমাকে সেই মাস্কটি পুনরায় সেট করতে হবে।

ডিফল্টরূপে সুরক্ষা বেশ কার্যকর f

https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

যেভাবেই হোক, এটি এখন লিনাক্সের মতোই, সুতরাং এগুলি ঘিরে কাজ করার জন্য কেবল এসিএল ব্যবহার করুন।

Answer 6

Http://en.wikedia.org/wiki/Setuid#setuid_and_setgid_on_directories অনুসারে ইউএনআইএক্স এবং লিনাক্স উভয় সিস্টেমের ডিরেক্টরিতে সেটুইড বিট উপেক্ষা করা হয়। যদিও আপনি ফ্রিবিএসডি-তে প্রত্যাশা মতো কাজ করেছেন এটি করা সম্ভব।

Comments

সহায়ক নয় - আমি জিজ্ঞাসা করেছি কেন setuidডিরেক্টরিগুলির জন্য উপেক্ষা করা হয়েছিল এবং যদি এটি লিনাক্সে স্বীকৃত করা সম্ভব হয়।

— ব্ল্যাকলাইট জ্বলজ্বল

এটি লিনাক্সে উপেক্ষা করার বিষয়টি সুস্পষ্ট বলে মনে হচ্ছে কারণ এটি ইউনিক্সে উপেক্ষা করা হয়েছে, এটি লিনাক্সকে আসল * নিক্সের সাথে মানিয়ে নিতে সঠিক আচরণ করে। প্রশ্নে নিবন্ধটি নির্দ্বিধায় পড়ুন। 2004 থেকে সবুজ উত্তর. org.uk/rjk/tech/perms.html এ একই উত্তর, সার্ভারফল্ট / প্রশ্ন

— 371541

তাহলে কেন এটি ইউনিক্সে উপেক্ষা করা হচ্ছে?

— আইজাক রবিনোভিচ

@ আইস্যাকআরবিনোভিচ যেহেতু ব্ল্যাকলাইট এটি পরিষ্কার করেছে যে প্রশ্নটি লিনাক্স সম্পর্কে, এটি প্রাসঙ্গিক নয় [গালে জিহ্বা] তবে আমি সন্দেহ করি এর একমাত্র অপরিবর্তিত আচরণ যেখানে একাধিক ইউনিক্স এটির সাথে বিভিন্ন কাজ করেছে এবং কিছুই না করা একটি নিরাপদ অনুমান।

— মাইকবাবকক

প্রশ্নটি / হয় / ট্যাগ করা হয় linux, হ্যাঁ, তবে এর অর্থ এই নয় যে আমি একটি অস্পষ্টতাকে পছন্দ করব "অন্যান্য সিস্টেমে এটি এভাবেই করা হয়" উত্তরটি উত্তর দেয় যা অন্য সিস্টেমে কেন এইভাবে করা হয় তা ব্যাখ্যা করে। (সম্ভবত linuxট্যাগটি সরানো উচিত?)

— ব্ল্যাকলাইট জ্বলজ্বল