Linux Namespaces গভীরে — সাতটি isolation primitive-এর ভেতরের যন্ত্র

PID namespace — শুধু নম্বরিং না, একটা গভীর সিগন্যাল-হ্যান্ডলিং quirk

namespaces-and-cgroups লেসন দেখিয়েছিল একটা process একাধিক namespace-এ একাধিক PID নিয়ে দৃশ্যমান হতে পারে, আর namespace-এর PID 1 মারা গেলে kernel পুরো namespace-এ SIGKILL পাঠায়। এখন কেন এই আচরণ, তার আসল উত্তর।

PID 1-এর জন্য সিগন্যালের নিয়ম আলাদা

সাধারণ কোনো process যদি একটা সিগন্যালের (যেমন SIGTERM) জন্য নিজের sigaction() handler ইনস্টল না করে, kernel তার default disposition প্রয়োগ করে — SIGTERM-এর ডিফল্ট হলো process টার্মিনেট করা। কিন্তু PID 1 (host-এর systemd/init হোক বা একটা container namespace-এর ভেতরের PID 1 হোক) — কোনো namespace-এর তোয়াক্কা না করেই — এই ডিফল্ট আচরণ থেকে exempt। যদি PID 1 নিজে কোনো signal-এর জন্য handler ইনস্টল না করে, kernel সেই সিগন্যাল চুপচাপ উপেক্ষা করে — এমনকি SIGTERM, SIGINT-এর মতো সাধারণত-প্রাণঘাতী সিগন্যালও।

সাধারণ process, handler নেই, SIGTERM পেল  → kernel default disposition চালায় → process টার্মিনেট
PID 1 (namespace-এর ভেতরে হোক বা host-এ), handler নেই, SIGTERM পেল → kernel সিগন্যাল ফেলে দেয় → কিছুই হয় না

এটা ইচ্ছাকৃত kernel ডিজাইন — একটা দুর্ঘটনাক্রমে পাঠানো সিগন্যাল যেন পুরো সিস্টেমের (বা namespace-এর) init process-টাকেই মেরে না ফেলে, যেটা একটা বিপর্যয়কর ব্যর্থতা হতো। কিন্তু এই একই সুরক্ষা যখন একটা অসতর্ক container image-এর entrypoint-এ প্রযোজ্য হয়, তখন এটা একটা বাস্তব বাগে পরিণত হয়, যা এখনই দেখব।

দ্বিতীয় দায়িত্ব — orphan reaping, বাধ্যতামূলক

PID 1-এর (host-এ হোক বা namespace-এ) আরেকটা কাজ যা কোনো ঐচ্ছিক সুবিধা না, বরং কার্যত বাধ্যতামূলক — যখন কোনো process-এর parent মারা যায় (process-anatomy/fork-exec-wait-জাতীয় লেসনের orphan/zombie আলোচনার সরাসরি প্রয়োগ), সেই orphan child-কে PID 1-এর কাছে reparent করা হয়। PID 1-এর দায়িত্ব সেই child শেষ পর্যন্ত exit করলে তার উপর wait()/waitpid() কল করে zombie entry-টা reap করা — যদি না করে, zombie process table-এ চিরকাল আটকে থাকে।

host-এ systemd এই কাজ যত্ন সহকারে করে। কিন্তু একটা সাধারণ Docker image-এর entrypoint — ধরুন একটা raw node server.js বা python app.py — এমনভাবে লেখা হয়নি যে সে জানে সে PID 1 হয়ে যাবে। এটা কখনো SIGCHLD handle করে না, কখনো waitpid() কল করে না, কারণ প্রোগ্রামটা এভাবে ডিজাইনই করা হয়নি (একটা normal process হিসেবে, যেখানে তার parent shell orphan-দের সামলাবে ধরে নিয়ে)।

সমাধান — একটা real init process

এই কারণেই container ecosystem-এ tini আর dumb-init-এর মতো ছোট টুল জন্ম নিয়েছে। এদের কাজ একটাই — PID 1 হিসেবে চলা, container-এর আসল entrypoint-কে child হিসেবে spawn করা, আর তারপর PID 1-এর দুইটা দায়িত্বই সঠিকভাবে পালন করা:

১. সিগন্যাল (SIGTERM, SIGINT) সঠিকভাবে forward করা মূল প্রোগ্রামের দিকে (যেহেতু PID 1 নিজে সেগুলো উপেক্ষা করত যদি handler না থাকত) ২. SIGCHLD handle করে যেকোনো orphaned zombie নিয়মিত waitpid() দিয়ে reap করা

PID 1 = tini
  └── PID 2 = app.py (আসল entrypoint, tini-এর child হিসেবে চলছে)
        └── PID 3 = subprocess (app.py-এর child)

এই ব্যবস্থায় app.py-কে আর কখনো PID 1 হতে হয় না — সে একটা সাধারণ, স্বাভাবিক PID 2 process, যার নিজস্ব parent (tini) আছে যে তার orphan-দের সামলাবে। Docker-এর নিজস্ব --init ফ্ল্যাগ (docker run --init ...) ঠিক tini-কেই ইনজেক্ট করে দেয় PID 1 হিসেবে, ব্যবহারকারীর image পরিবর্তন না করেই।

Network namespace — একটা সম্পূর্ণ, খালি স্ট্যাক থেকে শুরু

নতুন network namespace (CLONE_NEWNET) মানে সম্পূর্ণ আলাদা network stack — নিজস্ব interface তালিকা, নিজস্ব routing table, নিজস্ব iptables/nftables rule set, নিজস্ব port space। কিন্তু একটা সূক্ষ্ম, প্রায়ই ভুল বোঝা ডিটেইল আছে: এই নতুন namespace সম্পূর্ণ খালি না।

Loopback আছে, কিন্তু DOWN

প্রতিটা নতুন network namespace একটা lo (loopback) interface নিয়ে শুরু হয় — কিন্তু ডিফল্টভাবে সেটা প্রশাসনিকভাবে DOWN অবস্থায় থাকে। যদি namespace-এর ভেতরের কোনো প্রোগ্রাম 127.0.0.1-এ connect করার চেষ্টা করে, এই ধাপটা এড়িয়ে গেলে ব্যর্থ হবে — Connection refused বা Network is unreachable।

ip netns add mybox
ip netns exec mybox ip addr show lo

1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

লক্ষ করুন state DOWN — device বিদ্যমান, কিন্তু নিষ্ক্রিয়। এটাকে সক্রিয় করতে হয় explicit-ভাবে:

ip netns exec mybox ip link set lo up
ip netns exec mybox ip addr show lo

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever

এখন state UP, আর 127.0.0.1 কাজ করবে। container runtime-গুলো (runc-সহ) এই ধাপটা স্বয়ংক্রিয়ভাবে করে namespace তৈরির অংশ হিসেবে — কিন্তু হাতে raw unshare --net চালালে এই ধাপ মনে করে করতে হয়, নাহলে localhost-নির্ভর যেকোনো কোড (অনেক dev server, database client) ব্যর্থ হবে।

দুই container, একই port, কোনো সংঘর্ষ নেই

Network namespace-এর সবচেয়ে ব্যবহারিক ফল — port space namespace-স্কোপড। দুইটা container একই সাথে port 80-এ bind করতে পারে, কারণ প্রতিটার নিজস্ব, সম্পূর্ণ আলাদা port space:

Container A (net ns X): bind(0.0.0.0:80)  → সফল, X namespace-এর port 80 দখল
Container B (net ns Y): bind(0.0.0.0:80)  → সফল, Y namespace-এর port 80 দখল — কোনো conflict নেই
Host (root net ns):     bind(0.0.0.0:80)  → এটাও সফল হতে পারে — সম্পূর্ণ তৃতীয় একটা namespace

এটাই docker run -p 8080:80 আর docker run -p 8081:80-এর মতো কমান্ড একই সাথে চালানো সম্ভব করে — প্রতিটা container ভেতরে ভাবছে সে একাই port 80 ব্যবহার করছে, host-এর তরফ থেকে ভিন্ন external port-এ map হয়ে দৃশ্যমান হচ্ছে।

Mount namespace — নাম বিভ্রান্তিকর, mechanics গুরুত্বপূর্ণ

প্রথমে একটা ছোট কিন্তু বিরক্তিকর ঐতিহাসিক ব্যাপার: mount namespace-এর flag-এর নাম CLONE_NEWNS — কোনো “MOUNT” শব্দ নেই flag-এর নামে। এটা ঐতিহাসিক কারণে — mount namespace ছিল প্রথম namespace type (২০০২), তখন ধরে নেওয়া হয়েছিল এটাই একমাত্র namespace ধরনের হবে, তাই generic নাম NEWNS (“new namespace”) ব্যবহার করা হয়েছিল। পরে আরও ছয়টা namespace type যোগ হলে সবাই যথাযথ নির্দিষ্ট নাম পায় (NEWPID, NEWNET, ইত্যাদি), কিন্তু প্রথমটার নাম আর বদলানো যায়নি — backward compatibility ভাঙত। ফলাফল: আজও CLONE_NEWNS মানেই “mount namespace”, যদিও নামে সেটা স্পষ্ট না।

chroot() বনাম pivot_root() — নির্ভুল পার্থক্য

এটাই এই সেকশনের কেন্দ্রীয় প্রশ্ন। দুইটাই “root পরিবর্তন করে” মনে হয়, কিন্তু গ্যারান্টি সম্পূর্ণ ভিন্ন।

chroot(path) শুধু বদলায় একটা process-এর জন্য path resolution-এর apparent root। /-দিয়ে শুরু হওয়া যেকোনো path এখন path-এর সাপেক্ষে resolve হয়। কিন্তু:

• পুরনো root filesystem এখনও mounted আছে — শুধু নতুন root-এর ভেতর থেকে সরাসরি path দিয়ে পৌঁছানো যায় না।
• যদি process-এর কাছে পুরনো root-এর দিকে একটা খোলা file descriptor (একটা directory-র fd) আগে থেকেই থাকে, সে সেই fd দিয়ে fchdir() করে পুরনো root-এ ফিরে যেতে পারে — এটাই ক্লাসিক “chroot escape” কৌশল, কয়েক দশক ধরে পরিচিত।
• chroot()-এর জন্য CAP_SYS_CHROOT capability লাগে, কিন্তু এটা কখনোই একটা namespace mechanism ছিল না — এটা mount namespace আসারও অনেক আগে থেকে বিদ্যমান একটা পুরনো, সাধারণ syscall (BSD থেকে উত্তরাধিকারসূত্রে)।

/* ক্লাসিক chroot escape — সরলীকৃত ধারণা */
int old_root_fd = open("/", O_RDONLY);  /* escape-এর আগেই খোলা */
chroot("/new/restricted/root");
/* ... */
fchdir(old_root_fd);   /* পুরনো root-এ ফিরে যাওয়া, ফাইল descriptor দিয়ে */
chroot(".");            /* এখন apparent root-ও পুরনো root-এ ফিরিয়ে আনা */
/* এখন সম্পূর্ণ পুরনো filesystem আবার দৃশ্যমান — chroot ভাঙা হয়েছে */

pivot_root(new_root, put_old) সম্পূর্ণ ভিন্ন গ্যারান্টি দেয় — এটা আসলে বদলে দেয় কোন mounted filesystem “root” হিসেবে গণ্য হবে। বর্তমান root mount সরিয়ে put_old directory-তে বসানো হয় (এখনও mounted, কিন্তু এখন root-এর একটা sub-mount হিসেবে), আর new_root নতুন root হয়ে যায়। এরপর, গুরুত্বপূর্ণভাবে, container tooling সাধারণত পরবর্তী ধাপে সেই পুরনো root unmount করে দেয়:

/* container tooling-এর সাধারণ pattern, সরলীকৃত */
mount(NULL, "/", NULL, MS_REC | MS_PRIVATE, NULL);  /* propagation বিচ্ছিন্ন করা — namespaces-and-cgroups লেসনের callout */
pivot_root(new_root, old_root_path);  /* new_root -> নতুন "/", পুরনো "/" -> old_root_path-এ */
chdir("/");
umount2(old_root_path, MNT_DETACH);   /* পুরনো root সম্পূর্ণ unmount — এখন আর সেখানে কিছুই নেই */
rmdir(old_root_path);

এই শেষ umount2() ধাপের পর, পুরনো root filesystem-এর সাথে কোনো mount-tree সংযোগই আর নেই — কোনো খোলা fd দিয়ে fchdir() করলেও আর পুরনো ফাইলগুলো ফিরে পাওয়া যায় না, কারণ সেই filesystem আর mounted-ই না। এটাই মূল পার্থক্য: chroot শুধু দেখার কোণ বদলায় (path resolution), pivot_root প্রকৃতপক্ষে সরিয়ে দেয় কোন filesystem root — আর তারপর পুরনোটাকে সম্পূর্ণ বিচ্ছিন্ন করে দেওয়া যায়।

UTS namespace — সবচেয়ে সহজ, কিন্তু সেটাই তার শিক্ষামূলক মূল্য

CLONE_NEWUTS isolate করে শুধু দুইটা জিনিস — hostname আর NIS domainname। কোনো filesystem, কোনো network setup, কোনো UID mapping জড়িত না। sethostname("mybox") কল করলে শুধু বর্তমান namespace-এর hostname বদলায়:

unshare(CLONE_NEWUTS);
sethostname("mybox", 6);
/* এই process আর তার children এখন hostname "mybox" দেখবে
   parent namespace-এর hostname একদম অপরিবর্তিত থাকবে */

এই সরলতার কারণেই UTS namespace প্রায়ই “namespace isolation” ধারণার সবচেয়ে ভালো প্রথম demonstration — কোনো জটিল setup ছাড়াই একটা visible, তাৎক্ষণিক প্রমাণ পাওয়া যায় যে namespace সত্যিই কাজ করছে।

IPC namespace — id space, বাস্তব বিচ্ছিন্নতা সহ

CLONE_NEWIPC System V IPC-র id space আলাদা করে — semaphore, shared memory segment, message queue-র জন্য shmget()/semget()/msgget() যে integer id ফেরত দেয়, সেগুলো এখন namespace-স্কোপড। সাথে POSIX message queue-ও (/dev/mqueue-এর ভেতরের entry)।

গুরুত্বপূর্ণ ব্যবহারিক প্রভাব: দুইটা container একই সংখ্যার IPC id (যেমন উভয়েই shmget() থেকে id 5 পেল) ব্যবহার করতে পারে, অথচ তারা সম্পূর্ণ ভিন্ন, বিচ্ছিন্ন kernel object পাবে — একে অপরের shared memory content দেখতে বা touch করতে পারবে না। এটা মূলত একটা নিরাপত্তা বৈশিষ্ট্য, কিন্তু এর একটা সূক্ষ্ম ফলও আছে — legacy সফটওয়্যার যা একটা নির্দিষ্ট, hardcoded IPC key প্রত্যাশা করে (পুরনো database সার্ভার, কিছু scientific computing কোড), সেগুলো namespace-এর ভেতরে চালানো নিরাপদ, কারণ একই key ব্যবহার করা একাধিক instance একে অপরের data-তে দুর্ঘটনাক্রমে ধাক্কা খাবে না।

User namespace — সবচেয়ে জটিল, তাই এখানে সবচেয়ে বেশি সময়

namespaces-and-cgroups লেসন একটা একক-UID mapping দেখিয়েছিল (0 1000 1)। বাস্তব container runtime-এ mapping প্রায়ই একাধিক রেঞ্জ নিয়ে গঠিত — এখানে সম্পূর্ণ mechanics, একাধিক রেঞ্জ সহ।

uid_map ফরম্যাট — নির্ভুলভাবে

/proc/[pid]/uid_map-এ প্রতিটা লাইনের ফরম্যাট তিনটা সংখ্যা, space দিয়ে আলাদা করা:

<namespace-এর শুরু ID>  <host-এর প্রকৃত শুরু ID>  <রেঞ্জের দৈর্ঘ্য>

একটা বাস্তবসম্মত, দুই-লাইনের mapping যা rootless container tooling (Podman, rootless Docker) সাধারণত newuidmap-এর মাধ্যমে সেট করে:

0       1000        1
1       100000      65536

এর মানে:

• namespace UID 0 (root) ↔ host UID 1000 (এই ব্যবহারকারীর নিজের, স্বাভাবিক UID) — একটা একক ID, দৈর্ঘ্য ১
• namespace UID 1 থেকে 65536 (৬৫৫৩৬টা ধারাবাহিক ID) ↔ host UID 100000 থেকে 165535 — /etc/subuid-এ বরাদ্দকৃত একটা “subordinate UID” রেঞ্জ, যা root-privilege ছাড়াই এই ব্যবহারকারীকে দেওয়া হয়েছে ঠিক এই কাজের জন্য

Translation-এর গণিত — একটা offset যোগ করা, ব্যস

namespace UID থেকে host UID বের করার নিয়ম প্রতিটা রেঞ্জের জন্য একই: namespace UID যদি একটা রেঞ্জের ভেতরে পড়ে, তার offset (রেঞ্জের শুরু থেকে দূরত্ব) বের করে সেই একই offset host-রেঞ্জের শুরুতে যোগ করা।

$\text{host\_uid} = \text{host\_start} + (\text{ns\_uid} - \text{ns\_start}) \quad \text{যদি } \text{ns\_start} \le \text{ns\_uid} < \text{ns\_start} + \text{length}$

উদাহরণ — namespace UID 500, দ্বিতীয় রেঞ্জে পড়ে (1 থেকে 65536):

$\text{host\_uid} = 100000 + (500 - 1) = 100499$

আর যদি namespace UID কোনো রেঞ্জেই না পড়ে (mapping-এর বাইরে), kernel সেটাকে map করে একটা বিশেষ overflow UID-এ, ডিফল্টভাবে 65534 (/proc/sys/kernel/overflowuid-এ কনফিগারযোগ্য) — যেটা সাধারণত nobody user-এর UID, ইচ্ছাকৃতভাবে একটা প্রায়-privilege-বিহীন পরিচয়।

এই ঠিক এই গণিতটাই — একাধিক রেঞ্জ, offset যোগ, overflow fallback — পরের experiment/build অংশে একটা সত্যিকার, চালানো Python প্রোগ্রামে বাস্তবায়িত ও verify করা হবে।

কেন এটাই rootless container-এর ভিত্তি

kernel-এর প্রতিটা capability check (ns_capable() ফাংশন, যেটা CAP_SYS_ADMIN-এর মতো capability যাচাই করে) একটা নির্দিষ্ট user namespace-এর সাপেক্ষে কাজ করে, global ভাবে না। একটা process যদি তার নিজের user namespace-এ UID 0-এ mapped থাকে:

• সেই namespace-এর নিজস্ব resource-এর উপর (তার নিজের mount namespace-এ mount করা কিছু, তার নিজের net namespace-এর ভেতরের virtual device) সে সত্যিকারের root-এর ক্ষমতা পায়।
• কিন্তু host-এর প্রকৃত ফাইল, প্রকৃত process, প্রকৃত network-এর উপর — kernel যাচাই করে দেখে এই UID প্রকৃতপক্ষে (mapping অনুযায়ী) host-এ কে, আর সেই হিসেবে তার কোনো বাড়তি ক্ষমতা নেই। উপরের উদাহরণে namespace-এর “root” আসলে host UID 1000 — একজন সাধারণ, unprivileged ব্যবহারকারী।

এটাই সেই একটা যন্ত্র যা Podman-এর rootless mode, rootless Docker, আর বেশিরভাগ আধুনিক container runtime-কে কোনো root daemon ছাড়াই কাজ করতে দেয় — সম্পূর্ণ প্রক্রিয়াটা একজন সাধারণ ব্যবহারকারীর privilege-এ চলে, অথচ container-এর ভেতর থেকে সবকিছু “root হিসেবে” দেখায়।

Cgroup namespace — সবচেয়ে নতুন, সবচেয়ে সরল উদ্দেশ্য

CLONE_NEWCGROUP (২০১৬, সাতটার মধ্যে সবচেয়ে নতুন) একটু ভিন্ন ধরনের isolation দেয় — এটা resource limit করে না (সেটা cgroup নিজেই করে, namespace না), বরং isolate করে cgroup hierarchy-র দৃশ্যমান অংশ। এই namespace ছাড়া, একটা container-এর ভেতর থেকে /proc/self/cgroup পড়লে host-এর সম্পূর্ণ cgroup path দেখা যেত (যেমন /docker/a1b2c3.../), যা container-এর ভেতরের সফটওয়্যারের কাছে বিভ্রান্তিকর ও তথ্য-ফাঁসকারী (host-এর directory structure সম্পর্কে ইঙ্গিত দেয়)। cgroup namespace-এর সাথে, container-এর ভেতর থেকে সেই path দেখায় নিজের cgroup-কেই root (/) হিসেবে — ঠিক যেমন mount namespace filesystem root-কে re-anchor করে, cgroup namespace cgroup hierarchy-র root-কে re-anchor করে।