পাঠ ৪৬ · ৫৬-এর মধ্যে · মডিউল ১১
Home / Courses / Operating Systems (OS) / প্রোটেকশন ডোমেইন

প্রোটেকশন ডোমেইন ও অ্যাক্সেস ম্যাট্রিক্স

Protection domains & the access matrix
৮ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • প্রোটেকশন ডোমেইনের সংজ্ঞা ও এটি কীভাবে L01/L03-এর প্রোটেকশন ধারণাকে সুনির্দিষ্ট করে
  • অ্যাক্সেস ম্যাট্রিক্স মডেল — সারি, কলাম ও সেলের অর্থ
  • ACL ও ক্যাপাবিলিটি লিস্ট — একই ম্যাট্রিক্সের দুটি ভিন্ন প্রায়োগিক রূপ
  • বাস্তব কোড দিয়ে দেখা কেন প্রতিটি রিপ্রেজেন্টেশন তার নিজের প্রশ্নের জন্য স্বাভাবিক, অন্যটির জন্য নয়

১ · প্রোটেকশন ডোমেইন

প্রোটেকশন ডোমেইনProtection Domainএকটি প্রসেস কোন অবজেক্টে কোন অপারেশন করতে পারে — সেই (object, permitted-operations) জোড়ার সম্পূর্ণ সেট। সংজ্ঞায়িত করে একটি প্রসেস ঠিক এই মুহূর্তে কী করতে পারে — কোন ফাইল পড়তে/লিখতে পারে, কোন ডিভাইস অ্যাক্সেস করতে পারে, ইত্যাদি। এটি L01-এর প্রোটেকশন থিম ("একটি বাগযুক্ত প্রোগ্রাম অন্য প্রোগ্রামের মেমরি নষ্ট করতে পারে না") ও L03-এর সিস্টেম কল/দ্বৈত-মোড ধারণার একটি সুনির্দিষ্ট, প্রয়োগযোগ্য রূপ — একটি ডোমেইন হলো ঠিক সেই সীমারেখা যা প্রতিটি সিস্টেম কল ও হার্ডওয়্যার-স্তরের চেক বলবৎ করে।

২ · অ্যাক্সেস ম্যাট্রিক্স মডেল

অ্যাক্সেস ম্যাট্রিক্স সম্পূর্ণ প্রোটেকশন সিস্টেমকে একটি একক, পরিষ্কার মডেলে প্রকাশ করে — সারিগুলো ডোমেইন (প্রসেস/ইউজার), কলামগুলো অবজেক্ট (ফাইল, ডিভাইস), এবং প্রতিটি সেল সেই নির্দিষ্ট ডোমেইনের সেই নির্দিষ্ট অবজেক্টের উপর অনুমোদিত অপারেশনের সেট ধারণ করে। এটি তাত্ত্বিকভাবে সম্পূর্ণ ও নির্ভুল — কিন্তু বাস্তব সিস্টেমে ডোমেইন ও অবজেক্টের সংখ্যা বিশাল হওয়ায় (আর অধিকাংশ সেলই খালি, অর্থাৎ ম্যাট্রিক্সটি sparse) পুরো ম্যাট্রিক্স আক্ষরিকভাবে সংরক্ষণ করা অব্যবহারিক।

ডোমেইন \ অবজেক্ট File1 File2 Printer Process_A Read, Write Read -- (নেই) Process_B Read Read, Write Print Admin Read, Write Read, Write Print
একটি উদাহরণ অ্যাক্সেস ম্যাট্রিক্স — নিচের কোড সেলে ঠিক এই একই ডেটা থেকে ACL ও ক্যাপাবিলিটি লিস্ট দুটোই তৈরি করা হয়েছে।

৩ · দুটি বাস্তব ইমপ্লিমেন্টেশন — ACL বনাম ক্যাপাবিলিটি লিস্ট

ACLAccess Control Listম্যাট্রিক্স কলাম-ভিত্তিক সংরক্ষণ করা — প্রতিটি অবজেক্ট নিজেই জানে কোন কোন ডোমেইন তাকে কীভাবে অ্যাক্সেস করতে পারে। (Access Control List)
ম্যাট্রিক্স কলাম অনুযায়ী সংরক্ষণ করা হয় — প্রতিটি অবজেক্ট নিজেই একটি তালিকা রাখে কোন ডোমেইন তাকে কী করতে পারে। "এই ফাইলে কে অ্যাক্সেস করতে পারে?" প্রশ্নের স্বাভাবিক উত্তর — সরাসরি সেই ফাইলের তালিকা দেখলেই হয়।
ক্যাপাবিলিটি লিস্ট (Capability List)
ম্যাট্রিক্স সারি অনুযায়ী সংরক্ষণ করা হয় — প্রতিটি ডোমেইন/প্রসেস নিজেই একটি তালিকা রাখে সে কোন কোন অবজেক্ট অ্যাক্সেস করতে পারে ও কীভাবে। "এই প্রসেস কী অ্যাক্সেস করতে পারে?" প্রশ্নের স্বাভাবিক উত্তর — এবং একটি ক্যাপাবিলিটি অন্য প্রসেসকে দেওয়াও (delegate) সম্ভব, ACL-এ যা স্বাভাবিক নয়।
একই ডেটা, দুটি ভিন্ন "কোণ"

ACL ও ক্যাপাবিলিটি লিস্ট আসলে একই অন্তর্নিহিত অ্যাক্সেস ম্যাট্রিক্সের দুটি ভিন্ন "কাটা" — একটি কলাম বরাবর, একটি সারি বরাবর। কোনোটিই নতুন তথ্য যোগ করে না, শুধু একই তথ্যকে ভিন্নভাবে সংগঠিত করে ভিন্ন প্রশ্নের জন্য দ্রুত উত্তর দেওয়ার সুবিধা দেয়।

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

Python
# অ্যাক্সেস ম্যাট্রিক্স থেকে ACL ও ক্যাপাবিলিটি লিস্ট -- বাস্তব ইমপ্লিমেন্টেশন
# (toy in-memory ডেটা -- কোনো আসল ফাইল-সিস্টেম পারমিশন পরিবর্তন হয় না)

# মূল অ্যাক্সেস ম্যাট্রিক্স: {domain: {object: {allowed_operations}}}
access_matrix = {
    "Process_A": {"File1": {"read", "write"}, "File2": {"read"}, "Printer": set()},
    "Process_B": {"File1": {"read"}, "File2": {"read", "write"}, "Printer": {"print"}},
    "Admin":     {"File1": {"read", "write"}, "File2": {"read", "write"}, "Printer": {"print"}},
}

# --- ACL: কলাম-ভিত্তিক -- {object: {domain: allowed_operations}} ---
acl = {}
for domain, objects in access_matrix.items():
    for obj, ops in objects.items():
        acl.setdefault(obj, {})[domain] = ops

# --- ক্যাপাবিলিটি লিস্ট: সারি-ভিত্তিক -- {domain: {object: allowed_operations}} ---
capabilities = {}
for domain, objects in access_matrix.items():
    capabilities[domain] = {obj: ops for obj, ops in objects.items() if ops}


def who_can_access(obj, acl):
    """ACL-এ এটি O(1) সরাসরি লুকআপ -- এই অবজেক্টের এন্ট্রিই যথেষ্ট।"""
    return acl.get(obj, {})


def what_can_access(domain, capabilities):
    """ক্যাপাবিলিটি লিস্টে এটি O(1) সরাসরি লুকআপ -- এই ডোমেইনের এন্ট্রিই যথেষ্ট।"""
    return capabilities.get(domain, {})


print("প্রশ্ন ১: File2-এ কে কে অ্যাক্সেস করতে পারে? (ACL থেকে সরাসরি উত্তর)")
print(who_can_access("File2", acl))

print("\nপ্রশ্ন ২: Process_B কী কী অ্যাক্সেস করতে পারে? (ক্যাপাবিলিটি লিস্ট থেকে সরাসরি উত্তর)")
print(what_can_access("Process_B", capabilities))

print("\n--- বিপরীত প্রশ্নে খরচের পার্থক্য ---")
print("ACL দিয়ে 'Process_B কী অ্যাক্সেস করতে পারে?' জানতে পুরো ACL স্ক্যান করতে হতো:")
scanned = {obj: doms["Process_B"] for obj, doms in acl.items() if "Process_B" in doms}
print(f"  স্ক্যান করা এন্ট্রি সংখ্যা: {len(acl)} (যতগুলো অবজেক্ট আছে)  ->  ফলাফল: {scanned}")
print("ক্যাপাবিলিটি লিস্ট দিয়ে সরাসরি লুকআপে স্ক্যান করা এন্ট্রি সংখ্যা: 1")

    
লক্ষ্য করুন — who_can_access("File2", acl) ACL-এ একটি সরাসরি ডিকশনারি লুকআপ (O(1)), কিন্তু একই প্রশ্নের উত্তর ক্যাপাবিলিটি লিস্ট দিয়ে পেতে হলে প্রতিটি ডোমেইনের এন্ট্রি স্ক্যান করে দেখতে হতো File2 আছে কি না। ঠিক তার উল্টোটা ঘটে what_can_access("Process_B", ...)-এর ক্ষেত্রে — ক্যাপাবিলিটি লিস্টে সরাসরি, কিন্তু ACL দিয়ে পুরো স্ক্যান লাগত (কোডে এই স্ক্যানটিই স্পষ্টভাবে দেখানো হয়েছে)। এটিই দেখায় কেন বাস্তব সিস্টেম প্রায়ই দুটোরই কোনো সংস্করণ ব্যবহার করে, যেটি যেখানে বেশি প্রাসঙ্গিক।
মূল কথা · Key takeaway

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

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একটি ক্যাপাবিলিটি অন্য প্রসেসকে "পাস" করা যায় বলে যে সুবিধার কথা বলা হলো, এর সম্ভাব্য বিপদ কী হতে পারে?

যদি একটি ক্যাপাবিলিটি অসাবধানে বা দূষিতভাবে একটি অবিশ্বস্ত প্রসেসের কাছে পৌঁছে যায়, সেই প্রসেসও এখন মূল মালিকের সমান অ্যাক্সেস পেয়ে যায় — কারণ ক্যাপাবিলিটি নিজেই "প্রমাণ" হিসেবে কাজ করে, এটি কে ধরে আছে তা যাচাই করে না। এই কারণে বাস্তব ক্যাপাবিলিটি-ভিত্তিক সিস্টেমে ক্যাপাবিলিটি ছড়ানো নিয়ন্ত্রণ করার জন্য অতিরিক্ত সুরক্ষা মেকানিজম (যেমন ক্যাপাবিলিটি জাল করা অসম্ভব করা, বা নির্দিষ্ট ক্যাপাবিলিটি পাস করার অনুমতিও আলাদাভাবে নিয়ন্ত্রণ করা) প্রয়োজন হয়।

প্র ০২ কোড সেলে Process_A-এর Printer এন্ট্রি খালি সেট set() ছিল, অথচ ক্যাপাবিলিটি লিস্ট তৈরির সময় সেটি বাদ পড়ে গেছে -- কেন?

কোডে capabilities[domain] = {obj: ops for obj, ops in objects.items() if ops} লেখা হয়েছে — if ops শর্তটি খালি সেট (falsy) বাদ দেয়। এটি ইচ্ছাকৃত — একটি ক্যাপাবিলিটি লিস্টে "কোনো অনুমতিই নেই" এমন একটি এন্ট্রি রাখার কোনো ব্যবহারিক লাভ নেই (Process_A আসলে Printer-এ কিছুই করতে পারে না), তাই সেটি বাদ দিয়ে লিস্টটি আরও কম্প্যাক্ট রাখা হয়েছে — এটিই sparse ম্যাট্রিক্সের ব্যবহারিক সুবিধা।

প্র ০৩ যদি Admin-এর প্রোটেকশন ডোমেইন পরিবর্তন করে তাকে Printer-এ অ্যাক্সেস প্রত্যাহার করতে হয়, ACL ও ক্যাপাবিলিটি লিস্ট প্রতিনিধিত্বে সেই পরিবর্তনটি কোথায় করতে হবে?

ACL-এ পরিবর্তনটি করতে হবে acl["Printer"]-এর ভেতরে "Admin" এন্ট্রি সরিয়ে — একটি একক, স্থানীয় পরিবর্তন, ঠিক সেই অবজেক্টের এন্ট্রিতেই। ক্যাপাবিলিটি লিস্টে পরিবর্তনটি করতে হবে capabilities["Admin"]-এর ভেতরে "Printer" এন্ট্রি সরিয়ে — এটিও একক, স্থানীয় পরিবর্তন, কিন্তু ভিন্ন জায়গায়। এই উদাহরণটি দেখায় "একটি নির্দিষ্ট অবজেক্টের সব অ্যাক্সেস বাতিল করা" (একটি ফাইল ডিলিট করার সময়) ACL-এ সহজ, কিন্তু "একটি নির্দিষ্ট ডোমেইনের সব অ্যাক্সেস বাতিল করা" (একটি ইউজার অ্যাকাউন্ট বাতিল করার সময়) ক্যাপাবিলিটি লিস্টে সহজ — আবারও একই প্যাটার্নের পুনরাবৃত্তি।

অনুশীলন

  1. চিন্তা করুন: Unix ফাইল পারমিশন সিস্টেম (owner/group/other + rwx বিট, L47-এ বিস্তারিত) কি ACL-এর কাছাকাছি, নাকি ক্যাপাবিলিটি লিস্টের কাছাকাছি?

    ACL-এর কাছাকাছি। প্রতিটি ফাইল নিজেই তার পারমিশন বিট বহন করে (কে owner, কোন group, বাকিদের কী অধিকার) — এটি কলাম-ভিত্তিক চিন্তাভাবনা, ঠিক যেমন ACL-এ প্রতিটি অবজেক্ট নিজের অ্যাক্সেস তালিকা বহন করে। "এই ফাইলে কে অ্যাক্সেস করতে পারে?" প্রশ্নের উত্তর ফাইলের পারমিশন বিট দেখেই সরাসরি পাওয়া যায় — ঠিক এই পাঠের ACL-এর সংজ্ঞার সাথে হুবহু মিলে যায়।

  2. পরীক্ষা করুন: উপরের কোড সেলে access_matrix-এ একটি নতুন ডোমেইন "Guest" যোগ করুন (যার শুধু File1-এ {"read"} অনুমতি থাকবে), Run চাপুন, এবং who_can_access("File1", acl)-এর আউটপুটে Guest দেখা যাচ্ছে কি না দেখুন।

    হ্যাঁ, দেখা যাবে। যেহেতু ACL access_matrix থেকে লুপ করে স্বয়ংক্রিয়ভাবে তৈরি হয় (কোনো হার্ডকোড করা তালিকা নয়), নতুন যেকোনো ডোমেইন যোগ করলেই সেটি সংশ্লিষ্ট অবজেক্টের ACL এন্ট্রিতে স্বয়ংক্রিয়ভাবে যুক্ত হয়ে যাবে — এটি দেখায় কেন ম্যাট্রিক্স থেকে ACL/ক্যাপাবিলিটি ডেরাইভ করা একটি রক্ষণাবেক্ষণযোগ্য প্যাটার্ন, দুটি প্রতিনিধিত্ব হাতে সিঙ্ক্রোনাইজ রাখার চেয়ে।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
SSD বনাম HDD স্টোরেজ