chown উপর ব্যাখ্যা (1) POSIX spec

Question

chownইউটিলিটির জন্য পসিক্স বৈশিষ্টটিতে সিনট্যাক্স (পূর্বে ) (জোর খনি) সম্পর্কে তার যুক্তিযুক্ত বিভাগে উল্লেখ করা হয়েছে :chown user:groupchown user.group

মালিক এবং গোষ্ঠী উভয়কেই নির্দিষ্ট করার 4.3 BSD পদ্ধতিটি POSIX.1-2-2008 এর এই ভলিউমে অন্তর্ভুক্ত ছিল কারণ:

• এমন কেস রয়েছে যেখানে chgrp এবং chown (কেবলমাত্র ব্যবহারকারী আইডি পরিবর্তিত হয়েছে) ইউটিলিটিগুলি ব্যবহার করে কাঙ্ক্ষিত শেষের অবস্থা অর্জন করা যায়নি। (যদি বর্তমান মালিক কাঙ্ক্ষিত গোষ্ঠীর সদস্য না হন এবং কাঙ্ক্ষিত মালিক বর্তমান গ্রুপের সদস্য না হন তবে শাউন () ফাংশন ব্যর্থ হতে পারে যদি না মালিক এবং গোষ্ঠী উভয়কে একই সময়ে পরিবর্তন করা হয়।)

আমি ভেবেছিলাম user:groupসিনট্যাক্সটি একটি সুবিধাজনক জিনিস। এখন উপরোক্ত সূচিত হয়েছে এমন কিছু জিনিস রয়েছে chown user:groupযা আপনি করতে পারেন না যা আপনি করতে পারবেন নাchgrp group; chown user

এখন এই পাঠ্যটি আমার কাছে অর্থবোধ করে না। ৪.৩ বিএসডি-তে, কেবলমাত্র রুটই মালিককে একটি ফাইল বদলে দিতে পারে তাই সে যে কোনও ক্ষেত্রেই বাধা দিতে পারে না।

এসআইএসভি এবং কয়েকটি অন্যান্য সিস্টেম কোনও ফাইলের মালিককে কোনও ফাইলের ব্যবহারকারী এবং গোষ্ঠীকে কোনও কিছুতে পরিবর্তন করার অনুমতি দেয় (বা অনুমতি দেওয়ার জন্য ব্যবহৃত হয়), কিন্তু সেই সিস্টেমেও উপরের পাঠ্যটি আমার কাছে বোঝায় না। ঠিক আছে, যদি কেউ একটি করে থাকে তবে পরে chown someone-else the-fileকেউ তা করতে পারে না chgrp something-else the-fileকারণ একজন আর ফাইলের মালিক না, তবে তার / তাকে chgrpপ্রথম (ফাইলের মালিক হিসাবে থাকা) এবং তার chownপরে বাধা দেওয়ার কিছুই নেই এবং এটি সেটাই নয় উপরে লেখা ঠিক বলছে।

আমি বুঝতে পারি না যে এবং প্রয়োজনীয় কাঙ্ক্ষিত মালিক বর্তমান গ্রুপের সদস্য না হওয়ায় সমস্যাটির সাথে কী সম্পর্ক রয়েছে।

তাহলে কী কী শর্তগুলির জন্য শাউন () ফাংশন ব্যর্থ হতে পারে যদি না মালিক এবং গোষ্ঠী উভয়ই একই সময়ে এবং কোন সিস্টেমে পরিবর্তিত হয় ?

Comments

@ রবার্ট, এই নিয়মগুলি কোন সিস্টেমে প্রয়োগ করা হবে? আমি জানি যে সিস্টেমে আপনি রুট হন এবং আপনি যা খুশি তা করতে পারেন বা আপনার ব্যবহারকারী 1 এবং আপনি কিছুই করতে পারবেন না। যদি আপনি ব্যবহারকারী 1, সিস্টেমের উপর নির্ভর করে হয় হয় তবে আপনি মালিককে যেভাবেই পরিবর্তন করতে পারবেন না, বা আপনি যখন পারেন তখন আপনি নিজের পছন্দমতো গ্রুপটি পরিবর্তন করতে পারেন এবং তারপরে ব্যবহারকারীরা যা যা পছন্দ করতে পারেন।

— স্টাফেন চেজেলাস

আমার নিজের ডিরেক্টরিতে থাকা ডিরেক্টরিতে যদি অন্য কারও মালিকানাধীন একটি ফাইল এবং গোষ্ঠীর আমি সদস্য নই তবে আমি অন্যান্য অনুমতিের কারণে পড়তে পারি। তারপরে আমার নিজের মালিক হওয়ার জন্য এটির অনুলিপি করা আমার পক্ষে সম্ভব এবং এর একটি নতুন গ্রুপ রয়েছে (যার জন্য আমি সদস্য)। সুতরাং chown me:my-group fileফাইলটি যদি এমন কোনও স্থানে থাকে যেখানে আমি পড়া / লেখার অ্যাক্সেস পড়ে (কোনও স্টিকি নেই) তবে ফাইলটি যদি আমাকে নন-রুট হিসাবে দেয় তবে ওএসের পক্ষে এটি সংরক্ষণের মতো হওয়া উচিত । আমি মালিক হিসাবে প্রথমে chgrp করতে পারিনি। আমি যে ফাইলটি তৈরি করতে পারি না তার ফলশ্রুতিতে আমি প্রথমে ছোটাছুটি করতে পারি না: আমি যে গ্রুপের সদস্য নই তার একটি ফাইলের মালিক আমার।

— ctrl-alt-delor

@ রিচার্ড, না এটি এতটা নিরাপদ হবে না । আপনার ফাইল অ্যাক্সেস নেই এমন ফাইলটি হার্ডলিঙ্কযুক্ত হতে পারে। যে সমস্ত সিস্টেমে আপনি নিজের মালিকানাধীন ফাইলগুলি লিংক করতে পারবেন (ডিফল্টরূপে লিনাক্সের মতো), তার অর্থ আপনার লিখিত অ্যাক্সেসের ডিরেক্টরিতে লিঙ্ক যুক্ত করে কোনও ফাইলের মালিকানা দাবি করতে পারেন।

— স্টাফেন চেজেলাস

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

— ctrl-alt-delor

Answer 1

মাইক্রোসফট Interix ইউনিক্স সাব-সিস্টেম (এখন অবসরপ্রাপ্ত) তার NT তে কার্নেল জন্য ব্যবহারকারীকে এবং গ্রুপ অনুমতিসহ ভিন্নভাবে একটু মোকাবিলা চেয়ে কিছু অন্যদের করুন:

ব্যবহারকারী এবং গোষ্ঠী সম্পর্কিত তথ্য সুরক্ষা অ্যাক্সেস ডেটাবেজে সংরক্ষণ করা হয় । ব্যবহারকারী এবং গোষ্ঠী উভয়ই একই ডাটাবেসে সংরক্ষিত থাকে তবে গ্রুপ এবং ব্যবহারকারীর নাম অবশ্যই অনন্য হতে হবে; কোনও গোষ্ঠীর ব্যবহারকারীর নাম এবং বিপরীতে থাকতে পারে না। (এই ডাটাবেসটি ইউনিক্সের ফাইল /etc/passwdএবং /etc/groupsফাইলগুলি প্রতিস্থাপন করে ।) ব্যবহারকারী এবং গোষ্ঠীগুলি যথাযথ উইন্ডোজ পদ্ধতি ব্যবহার করে (ইউজার ম্যানেজার, অ্যাক্টিভ ডিরেক্টরি ব্যবহারকারী এবং কম্পিউটার, বা স্থানীয় ব্যবহারকারী এবং গোষ্ঠী) বা উইন 32 net userকমান্ডের সাহায্যে তৈরি করা হয়। (ব্যবহারকারীদের তৈরি এবং অপসারণের জন্য শেল স্ক্রিপ্টগুলির উদাহরণ ডিরেক্টরিতে অন্তর্ভুক্ত রয়েছে /usr/examples/admin)) ব্যবহারকারীরা অনেকগুলি গ্রুপের অন্তর্ভুক্ত থাকতে পারেন।

এখানে আরও কিছু নির্দিষ্ট ম্যানুয়াল অংশ রয়েছে:

উইন্ডোজে, কোনও ব্যবহারকারী বা একটি গ্রুপ কোনও বস্তুর মালিক হতে পারে। এটি ইউনিক্স থেকে পৃথক, যেখানে কেবলমাত্র কোনও ব্যবহারকারী কোনও বস্তুর মালিক।

সুরক্ষা সনাক্তকারী (এসআইডি) ব্যবহার করে উইন্ডোজ অভ্যন্তরীণভাবে সমস্ত ব্যবহারকারী এবং গোষ্ঠী সনাক্ত করে । একটি হ্যাশিং অ্যালগরিদম SID মান উত্পন্ন করে যা অনন্য; কোনও দুটি ব্যবহারকারী বা গোষ্ঠীর একই এসআইডি থাকবে না।

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

CHGRP

... ফাইলের জন্য গোষ্ঠী আইডি পরিবর্তন করুন ... ব্যবহারকারী chgrp (1) কে অনুরোধ করা অবশ্যই নির্দিষ্ট গোষ্ঠীর অন্তর্ভুক্ত এবং ফাইলটির মালিক হতে হবে, বা উপযুক্ত সুযোগগুলি থাকতে হবে।

chown

... মালিক এবং গ্রুপ অপারেশন উভয়ই alচ্ছিক; তবে, একটি নির্দিষ্ট করা আবশ্যক। গোষ্ঠী অপারেন্ডটি নির্দিষ্ট করা থাকলে এটি অবশ্যই একটি কোলন (:) এর আগে হওয়া উচিত।

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

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

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

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

এখানে একটি লিঙ্ক একটি এখন অপ্রচলিত সুরেলা বর্ণনা সোলারিস ডকুমেন্ট rstchownযা ...

chown(2)সিস্টেম কলের জন্য পসিক্স শব্দার্থক কার্যকর রয়েছে কিনা তা সূচিত করে ...

স্পষ্টতই, যদি প্যারামিটারটির মান সেট করা থাকে 0...

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

এই জাতীয় বিকল্পটি সোলারিসের পসিক্স কনফারেন্সকে অবৈধ করে না । এটি মোটামুটি একটি বিকল্প হিসাবে এটি উপযুক্ত হিসাবে যোগ্যতা অর্জন করে :

যদিও POSIX.1-2-2008 অনুসারে সমস্ত বাস্তবায়ন নীচে বর্ণিত সমস্ত বৈশিষ্ট্য সমর্থন করে তবে সিস্টেম-নির্ভর বা ফাইল সিস্টেম-নির্ভর কনফিগারেশন পদ্ধতি থাকতে পারে যা এই সমস্ত বৈশিষ্ট্য মুছে ফেলতে বা সংশোধন করতে পারে । কঠোরভাবে সম্মতি প্রয়োজন হলে এ জাতীয় কনফিগারেশন তৈরি করা উচিত নয়।

নিম্নলিখিত প্রতীকী ধ্রুবকগুলি -1 ব্যতীত অন্য কোনও মান দিয়ে সংজ্ঞায়িত করা হবে। একটি ধ্রুবক মান শূন্য সংজ্ঞায়িত করা হয়, তাহলে অ্যাপ্লিকেশন ব্যবহার করা উচিত sysconf(), pathconf()অথবা fpathconf()ফাংশন, বা getconfউপযোগ নির্ধারণ করতে থাকা বৈশিষ্টগুলি সময়ে বা প্রশ্ন বিশেষ পথনাম জন্য সিস্টেমে উপস্থিত থাকে।

_POSIX_CHOWN_RESTRICTED

ব্যবহারের chown()উপযুক্ত অধিকারসহ একটি প্রক্রিয়া অবধি সীমিত থাকবে, এবং শুধুমাত্র প্রক্রিয়ার কার্যকর গ্রুপ আইডি বা তার সম্পূরক গ্রুপ ID- র এক একটি ফাইলের গোষ্ঠী ID পরিবর্তন করতে।

chown()সিস্টেম ফাংশন - যা নথিভুক্ত সিস্টেম কল উভয় দ্বারা তৈরি হয় chownএবং chgrpশেল ইউটিলিটি - হয় ব্যর্থ নিদিষ্ট অসংখ্য কারণে। তাদের মধ্যে:

EACCES পথের উপসর্গের একটি অংশে অনুসন্ধানের অনুমতি অস্বীকৃত।

ELOOP পথ আর্গুমেন্টের সমাধানের সময় প্রতীকী লিঙ্কগুলিতে একটি লুপ উপস্থিত রয়েছে।

EPERM কার্যকর ব্যবহারকারীর আইডি ফাইলটির মালিকের সাথে মেলে না বা কলিং প্রক্রিয়াটিতে উপযুক্ত সুযোগ-সুবিধা নেই এবং _POSIX_CHOWN_RESTRICTED ইঙ্গিত দেয় যে এই ধরনের অধিকারের প্রয়োজন।

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

মূলত, ইউনিক্স কোনও ফাইলের মালিককে একটি ফাইল উপহার দেওয়ার অনুমতি দেয়। একটি ফাইলের মালিক অন্য কাউকে মালিক পরিবর্তন করতে পারে। কোনও রুটবিহীন ব্যবহারকারীর পক্ষে এই অপারেশনটি পূর্বাবস্থায় ফেলার কোনও উপায় ছিল না ... বিএসডি [পরে]chown নন-রুট ব্যবহারকারীদের থেকে অপসারণ করা হয়েছে ... [অংশে কারণ] ... এটি ডিস্ক কোটা প্রয়োগ করেছে যা ডিস্কের কত স্থান সীমাবদ্ধ করতে পারে ব্যবহারকারীর একটি ফাইল সিস্টেমে থাকতে পারে ... দুষ্টু ব্যবহারকারীরা কোটাগুলি ছিনিয়ে নিতে বড় ফাইলগুলি দিতে পারেন।

আজ, এটি বলা সহজ নয় যে কোনও রুট-অ- chownফাইল কোনও ফাইল করতে পারে কিনা । ইউনিক্সের অনেকগুলি সংস্করণ উভয় আচরণের অনুমতি দেয় ...

আর একটি ভাল - এবং আরও সাম্প্রতিক - মেলিং-তালিকা পোস্ট এটিকে উদ্ধৃত করে এবং চালিয়ে যায়:

বেশিরভাগ ওএসের সাথে ডিফল্টটি chownকেবলমাত্র রুটে সীমাবদ্ধ থাকে। এবং একটি sensকমত্য আছে যে এটি সুরক্ষা বিবেচনার জন্য এইভাবেই থাকা উচিত। যদি কোনও রুটহীন ব্যবহারকারী কোনও ফাইলের মালিক পরিবর্তন করে এবং কোনও এক্সিকিউট বিট চালু থাকে, SUIDএবং SGIDবিটগুলি সাফ করতে হবে। এটি হতে পারে বা নাও হতে পারে root।

আমি মনে করি যে শেষ অনুচ্ছেদটি এটি সুন্দরভাবে বলেছে।

এই নিবন্ধটি CAP_CHOWNলিনাক্সের সেই সুবিধাটি নিয়ন্ত্রণ করার জন্যও উল্লেখ করেছে (এটি কেবল POSIX_CHOWN_RESTRICTEDআচরণের উপর প্রভাব ফেলে ) । রয়েছে CAP_FOWNERসামর্থ্য, যে আচরণের একটু আলাদা।

এবং 2003 হিসাবে আপনি উল্লেখ করেছেন :

নোট করুন যে কমপক্ষে এইচপিইউজে আপনি নিজেরাই ব্যক্তিগতকৃত ব্যবহারকারী না হলেও আপনার ফাইলগুলির মালিককে ( rootউদাহরণস্বরূপ) পরিবর্তন করতে পারবেন ...

... যা একটি কনফিগারেশন setprivgroupপ্যারামিটার উপর নির্ভর করে ।

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

এই পরিস্থিতিতে chown তখন chgrp ব্যর্থ হয়ে যাবে কারণ ব্যবহারকারীর আর সেই ফাইলের অনুমতিগুলি পরিবর্তন করার অনুমতি থাকবে না, তবে chown user:group- যতক্ষণ গ্রুপ ব্যবহারকারীর নিজস্ব হিসাবে রয়েছে - সফল হবে।

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

ফাইল অনুমতি, ট্রি ট্রভারসাল এবং প্রতীকী লিঙ্কগুলির বিভিন্ন সম্ভাব্য প্রভাব সম্পর্কে বিস্তৃত ডকুমেন্টেশন রয়েছে যা এখানে -Rকর্মপরীক্ষার chownক্ষেত্রে একইরকম ব্যর্থতার প্রভাব ফেলতে পারে :

তৃতীয় এবং চতুর্থ ডোমেনগুলি পজিক্স এক্সআরএটি বিভাগের শিরোনাম থেকে :

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

... একটি লজিকাল ওয়াক এ ডিফল্ট সঙ্গে একটি সুরক্ষা সমস্যা আছে। ঐতিহাসিকভাবে, কমান্ড chown -Rব্যবহারকারী ফাইল সুপার-ইউজার জন্য নিরাপদ করা হয়েছে কারণ হয়েছে setuid এবং setgid বিট যখন ফাইলের মালিকানা পরিবর্তন করা হয়েছে হারিয়ে ছিল। যদি পদক্ষেপটি যৌক্তিক হয় তবে মালিকানা পরিবর্তন করা আর নিরাপদ থাকত না কারণ কোনও ব্যবহারকারী সম্ভবত গাছের কোনও ফাইলের দিকে ইঙ্গিত করে একটি প্রতীকী লিঙ্কটি sertedোকান। আবার, প্রতীকী লিঙ্কগুলির মাধ্যমে অপ্রত্যক্ষ না হওয়ার জন্য হায়ারার্কি ট্র্যাভার্সাল করার আদেশগুলিতে একটি বিকল্প সংযোজন করা আবশ্যক হবে এবং পুনরাবৃত্তিযোগ্য পদক্ষেপগুলি করা .তিহাসিক স্ক্রিপ্টগুলি তত্ক্ষণাত সুরক্ষার সমস্যা হয়ে উঠবে। যদিও এটি বেশিরভাগই সিস্টেম প্রশাসকদের ক্ষেত্রে একটি সমস্যা, তবে বিভিন্ন শ্রেণীর ব্যবহারকারীর জন্য আলাদা ডিফল্ট না থাকাই ভাল।

...

৪.৩ বিএসডি-তে, chgrpগাছের ট্র্যাভার্সাল চলাকালীন লক্ষ্য নয়, প্রতীকী লিঙ্কের গোষ্ঠী পরিবর্তন করেছে। ৪.৪ বিএসডিতে প্রতীকী লিঙ্কগুলির মালিক, গোষ্ঠী, মোড বা অন্যান্য মানক ইউনিক্স সিস্টেম ফাইলের বৈশিষ্ট্য নেই।

এবং পসিক্স chgrpপৃষ্ঠায় যথাযথভাবে এটি রয়েছে যা একটি সম্ভাব্য অসম্পূর্ণ -Rকর্মপরীক্ষা বা কমপক্ষে যা ব্যবহৃত হয়েছিল তা নির্দেশ করে:

সিস্টেম ভি এবং বিএসডি সংস্করণগুলি বিভিন্ন প্রস্থান স্থিতি কোড ব্যবহার করে। কিছু বাস্তবায়ন ঘটে যাওয়া ত্রুটির সংখ্যার গণনা হিসাবে প্রস্থান স্থিতি ব্যবহার করে; এই অনুশীলনটি অকার্যকর কারণ এটি বৈধ প্রস্থান স্থিতি মানের মানের সীমাকে ছাড়িয়ে যেতে পারে। প্রমিত বিকাশকারীরা কেবলমাত্র 0 এবং> 0 কে প্রস্থান করার মান হিসাবে উল্লেখ করে এগুলি মাস্ক করা বেছে নিয়েছিলেন।

Comments

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

— মাইকসার্ভ

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

— স্টাফেন চ্যাজেলাস

@ স্টাফেনচাজেলাস - আপনার প্রশ্নের কোনও দিক কি এই পোস্টের উত্তর দেয় না?

— মাইকজারভেজ

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

— স্টাফেন চেজেলাস

@ স্টাফেনচাজেলাস - আমি পয়েন্টগুলির জন্য যত্ন নিই না এবং কখনও করি নি। আমি কেবল আশা করছিলাম যে আমি এটিকে ঘৃণা করব না। আমি আত্মসমর্পণ করছি না যদিও এটি অংশটি ভাল হবে - আপনার অর্থ এনটি ইউনিক্স 4? মাইক্রোসফ্টের অফিসিয়াল ডকস পোক্স কমপ্লেক্সকে কমপক্ষে দাবি করেছেন যে যখন এটি এখনও ইন্টারিক্স ছিল, তখন আমি এবং তারা কিছুটা আশ্চর্যজনকভাবে chgrp chownবলে

— থাকি

Answer 2

আসাম্প্শান 1: নির্ধারণের কিনা জন্য নিয়ম chownসফল লক্ষ্য ব্যবহারকারী এবং গ্রুপ অংশের পরীক্ষা স্বাধীনভাবে, IE তারা ফর্ম হয় user_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters)।

অনুমান 2: chown(file, -1, -1)সফল হয়।

অনুমান 3: chownসাফল্য ফাইল বর্তমানে কোন গ্রুপের অন্তর্গত তা নির্ভর করে না তা নির্ধারণের নিয়ম ।

chown(file, uid, gid)বাস্তবায়ন : যদি সফল হয় তবে তাই হবে chown(file, -1, gid) && chown(file, uid, -1)।

আমি এমন কোনও ইউনিক্স বৈকল্প সম্পর্কে জানি না যা এই অনুমানগুলির কোনও লঙ্ঘন করবে, তারা বেশ নিরাপদ বলে মনে হচ্ছে।

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

---

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

---

একটি পুনরাবৃত্তি কলের জন্য, এমন প্রান্তের কেস রয়েছে যেখানে পুরো পাসের chgrpপরে সম্পূর্ণ পাস chownব্যর্থ হতে পারে যখন কোনও একক পাস সফল হয়। এটি খুব দৃinc়প্রত্যয়ী যুক্তি নয় কারণ এতে ডিরেক্টরি অন্তর্ভুক্ত রয়েছে যাতে মালিককে ট্র্যাভার করার অনুমতি নেই এবং এমন একটি অ্যাপ্লিকেশন যা এই জাতীয় সমস্ত মামলার বিরুদ্ধে রক্ষা করতে চেয়েছিল সেভাবেই অনুমতি নিয়ে গুঁজে দেওয়া উচিত। তবুও এটি প্রযুক্তিগতভাবে এই যুক্তির শর্ত পূরণ করে। ধরে নিন যে চলমান প্রক্রিয়াটির কার্যকর ব্যবহারকারী alice, কার্যকর গ্রুপ staffএবং ফাইল মালিকদের নির্বিচারে পরিবর্তন করার ক্ষমতা রয়েছে (কেবল তাদের ছেড়ে দেওয়ার জন্য নয়; বেশ কয়েকটি ইউনিক ভেরিয়েন্টের এমন ক্ষমতা রয়েছে যদিও এটি অ-রুট প্রক্রিয়াগুলিতে খুব কমই মঞ্জুর করা হয়)।

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied

Comments

নোট করুন যে পসিক্স কেবল ইউনিক্স সম্পর্কে নয়। অনেকগুলি নন-ইউনিক্স ওএস রয়েছে যার একটি পসিক্স সাবসিস্টেম / এপিআই রয়েছে (উদাহরণস্বরূপ মাইক্রোসফ্ট উইন্ডোজ এনটি)। আমি নিশ্চিত নই যে শর্তগুলি দাবী করার পক্ষে যথেষ্ট। chgrpবা chownপার্শ্ব প্রতিক্রিয়া আছে যা অন্য এক করতে ক্ষমতাকে প্রভাবিত হয়ে উঠতে পারে। উদাহরণস্বরূপ chownক্ষমতা সরিয়ে দেয় chgrp, এটি একটি সত্য fact chgrpসেটুইড / সেটজিড বিট সাফ করে, এটি এসিএলের কিছু ফর্ম বা সুরক্ষা প্রসঙ্গে অন্য রূপটি সাফ করতে পারে ...

— স্টাফেন চেজেলাস

@ স্টাফেনচাজেলাস আমরা সম্মত হই যে chownএরপরে chgrpব্যর্থ হতে পারে তবে প্রশ্নটি chgrpএরপরেই চলে chown। হুঁ, সুরক্ষা প্রসঙ্গে ... বাধ্যতামূলক অ্যাক্সেস নিয়ন্ত্রণ সহ এমন কোনও সিস্টেমে chgrpকোনও ফাইলকে কলঙ্কিত করে এটিকে আর চাওনযোগ্য করতে পারে না? এটি সুদূরপ্রসারী বলে মনে হচ্ছে।

— গিলস 'তাই খারাপ হওয়া বন্ধ করুন'

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

— স্টাফেন চেজেলাস

আপনার সর্বশেষ সম্পাদনা আবার। ক্লাউন -আর বব সহ: শিক্ষার্থীরা, এলিস এখনও অনুসন্ধানের অনুমতিগুলি looseিলে করে দেবে dir, কাজেই chownএটির জন্য প্রথমে ফাইলগুলির গভীরতা প্রক্রিয়া করা প্রয়োজন এবং এটির কোনও প্রয়োগের কথা আমার জানা নেই। সুতরাং এটি প্রায় বৈধ কেস যেখানে chgrp + chown ব্যর্থ হয়ে যায় যেখানে chmod u: g পারেন না, তবে এটি যুক্তিযুক্ত পাঠ্যের সাথে সত্যই যুক্ত হয় না।

— স্টাফেন চেজেলাস

পর্যালোচনা করা হয়নি এমন সচিবের ভুল প্রতিলিপি এবং এজ-কেস পুনরাবৃত্তি chownতত্ত্বগুলি বিরোধ হিসাবে দেখা দেয়।

— মাইকজার্ভ