Linux-এ user, group আর permission — rwx, setuid আর sudo

১ · User আর group — OS আপনাকে কী নামে চেনে

একটি অফিস ভবনের কথা ভাবুন। গেটে দারোয়ান সবার নাম মনে রাখেন না — তিনি দেখেন গলায় ঝোলানো পরিচয়পত্রের নম্বর। হিসাব বিভাগের কার্ডে লেখা “Accounts”, তাই তিনি হিসাব বিভাগের ঘরে ঢুকতে পারেন। আর ভবনের মালিকের কাছে একটি মাস্টার চাবি আছে, যা সব দরজা খোলে।

Linux-এ ঠিক এই ব্যবস্থা। পর্ব ৪৬-এ দেখেছেন কে কী করতে পারবে তার তাত্ত্বিক ছবি — domain, access matrix. এই পর্বে দেখব Linux সেই তত্ত্বকে কত সরলভাবে বাস্তবে রূপ দিয়েছে। প্রতিটি মানুষ বা সার্ভিসের জন্য একটি user account, আর kernel-এর কাছে তার পরিচয় একটি সংখ্যা: UID (user ID). কয়েকজনকে একসাথে অনুমতি দিতে আছে group, যার সংখ্যা GID. প্রতিটি প্রসেস যে user-এর হয়ে চলে, তার UID আর GID-গুলো প্রসেসের সাথে লেগে থাকে (পর্ব ০৮-এর PCB-তে)। প্রতিটি ফাইলের inode-এ লেখা থাকে মালিকের UID আর একটি GID (পর্ব ৪১). Permission-যাচাই মানে এই দুই জোড়া সংখ্যার তুলনা।

/etc/passwd — account-এর তালিকা

নাম থেকে সংখ্যা আর সংখ্যা থেকে নামের অনুবাদ থাকে /etc/passwd ফাইলে। প্রতি লাইনে একটি account, সাতটি ঘর, মাঝে :. নিচের দুটি লাইন এই পাতার কোড-রানারের container থেকে নেওয়া: প্রথমটি root-এর, যা প্রায় সব Linux-এ হুবহু এমন; দ্বিতীয়টি আমাদের sandbox-এর user, যা অংশ ৬-এর কোডে নিজেই দেখবেন।

root:x:0:0:root:/root:/bin/bash
wandbox:x:999:999::/home/wandbox:/bin/sh

অতিরিক্ত group-এর সদস্যপদ থাকে /etc/group-এ: নাম:x:GID:সদস্য১,সদস্য২. যেমন Ubuntu-তে sudo:x:27:ubuntu মানে “ubuntu” নামের user sudo group-এর সদস্য। একজন user-এর একটি প্রধান group আর কয়েকটি supplementary group থাকতে পারে; login-এর সময় সবগুলো প্রসেসের পরিচয়ে যোগ হয়। তাই কাউকে নতুন group-এ যোগ করলে নতুন login (বা নতুন session) না হওয়া পর্যন্ত চলমান shell-এ সেটি দেখা যায় না।

/etc/shadow — কেন আলাদা, কেন শুধু root

শুরুর দিকের Unix-এ পাসওয়ার্ডের hash /etc/passwd-এর দ্বিতীয় ঘরেই থাকত। কিন্তু /etc/passwd সবার পড়ার মতো হতেই হবে: ls -l যখন UID 999-কে “wandbox” লেখে, তখন যেকোনো user-এর প্রসেস এই ফাইল পড়ে। ফলে যে কেউ সবার hash কপি করে নিজের কম্পিউটারে বসে কোটি কোটি পাসওয়ার্ড অনুমান করে মিলিয়ে দেখতে পারত — একে বলে offline guessing, যেখানে login-এর ভুল-চেষ্টার সীমা কোনো কাজে আসে না। সমাধান ছিল ভাগ করা: নাম আর UID থাকুক সবার জন্য খোলা /etc/passwd-এ, আর password hash চলে যাক /etc/shadow-এ, যা শুধু root (আর Debian/Ubuntu-তে shadow group) পড়তে পারে।

rahim:$y$j9T$<salt>$<hash>:20387:0:99999:7:::
│     │  │    │      │       │     │ │     └ মেয়াদ শেষের কত দিন আগে সতর্ক করা হবে
│     │  │    │      │       │     │ └ সর্বোচ্চ কত দিন পর পাসওয়ার্ড বদলাতে হবে
│     │  │    │      │       │     └ বদলের পর অন্তত কত দিন অপেক্ষা
│     │  │    │      │       └ শেষ বদল: ১৯৭০-০১-০১ থেকে দিনের সংখ্যা
│     │  │    │      └ hash (একমুখী — এখান থেকে পাসওয়ার্ড ফেরত পাওয়া যায় না)
│     │  │    └ salt: প্রতি user-এ আলাদা এলোমেলো মান
│     │  └ পদ্ধতির পরামিতি
│     └ $y$ = yescrypt (নতুন Debian/Ubuntu), $6$ = SHA-512 crypt
└ নাম

দুটি জিনিস খেয়াল করুন। প্রথমত, এটি encryption নয় — একমুখী hash; সিস্টেম নিজেও আপনার পাসওয়ার্ড জানে না, login-এর সময় আপনার টাইপ করা লেখার hash বানিয়ে মিলিয়ে দেখে। দ্বিতীয়ত, প্রতি user-এর আলাদা salt থাকায় দুজনের একই পাসওয়ার্ড হলেও hash আলাদা হয়, আর yescrypt বা SHA-512 crypt-এর মতো পদ্ধতি ইচ্ছা করে ধীর, যাতে অনুমানের খরচ বাড়ে। দ্বিতীয় ঘরে ! বা * থাকলে পাসওয়ার্ড দিয়ে login বন্ধ — service account আর অনেক cloud সার্ভারের user এভাবেই থাকে (তারা SSH key দিয়ে ঢোকে)। Hash কীভাবে কাজ করে আর কেন ধীর hash নিরাপদ, তার বিস্তারিত পর্ব ৪৮-এ।

root, সাধারণ user আর service account

নিজের পরিচয় দেখার তিনটি কমান্ড: whoami (শুধু নাম), groups (group-গুলোর নাম), আর সবচেয়ে কাজের id — UID, প্রধান GID আর সব group, সংখ্যা ও নাম দুটোই। একটি সাধারণ Ubuntu ল্যাপটপে প্রথম user-এর id দেখতে এমন হতে পারে: uid=1000(rahim) gid=1000(rahim) groups=1000(rahim),4(adm),27(sudo). এখানে 27(sudo) group-এর সদস্যপদই তাকে sudo ব্যবহারের অধিকার দেয় (অংশ ৭)।

২ · Permission-এর মডেল — তিন শ্রেণি × তিন অধিকার

প্রতিটি ফাইলের inode-এ ১২টি অনুমতি-বিট থাকে (আর ধরন বোঝাতে আরও কয়েকটি)। নিচের ৯টি বিটই মূল: তিন শ্রেণির মানুষ — owner (u, user), group (g), other (o, বাকি সবাই) — আর প্রত্যেকের জন্য তিনটি অধিকার — r (read), w (write), x (execute). ওপরের ৩টি বিশেষ বিট (setuid, setgid, sticky) অংশ ৬-এ। ls -l-এর প্রথম কলামে file permission এভাবে পড়বেন:

একই অক্ষর, ফাইলে এক অর্থ, directory-তে আরেক

পর্ব ৪২-এ দেখেছেন, directory আসলে নাম → inode নম্বরের একটি তালিকা। এটি মনে রাখলে directory-র অনুমতি আর ধাঁধা থাকে না:

৩ · chmod, chown আর chgrp — অনুমতি বদলানো

chmod (change mode) দুইভাবে লেখা যায়। Symbolic রূপ পড়তে সহজ, আর শুধু যা বলবেন তা-ই বদলায়: u/g/o/a (all), তারপর + (যোগ), - (বাদ) বা = (ঠিক এটাই, বাকি মুছে), তারপর অধিকার। যেমন chmod g+w file, chmod o= file, chmod u+x,go-w file. Octal রূপে পুরো mode একবারে বসে: প্রতিটি শ্রেণির জন্য একটি অঙ্ক, যেখানে r = ৪, w = ২, x = ১ যোগ হয়। Octal মানে ৮-ভিত্তিক সংখ্যা, আর তিনটি বিট দিয়ে ঠিক ০ থেকে ৭ পর্যন্ত লেখা যায় — তাই তিন বিটের প্রতিটি দল একটি octal অঙ্ক (সংখ্যা-পদ্ধতির ঝালাই চাইলে Computer Fundamentals-এর সংখ্যা পদ্ধতি)।

চারটি রূপান্তর, হাতে-কলমে

চার অঙ্কের mode-এ প্রথম অঙ্কটি বিশেষ বিটের: setuid = ৪, setgid = ২, sticky = ১. ls -l-এ এগুলোর আলাদা ঘর নেই, তাই x-এর জায়গায় বসে — setuid owner-এর x-এর জায়গায় s, setgid group-এর x-এর জায়গায় s, sticky other-এর x-এর জায়গায় t. নিচে x না থাকলে বড় হাতের S/T — প্রায় সবসময় একটি ভুলের চিহ্ন।

উল্টো দিকেও অভ্যাস করুন: -rw-r--r-- → rw- = ৬, r-- = ৪, r-- = ৪ → 644. drwx------ → 700. এবার নিচের কোডটি চালিয়ে দেখুন — এটি এই পাতার sandbox-এ সাধারণ (root নয়) user wandbox হিসেবে চলে, নিজের ফোল্ডারে ফাইল বানিয়ে দুই রূপের chmod প্রয়োগ করে, আর stat -c '%a %A' দিয়ে octal ও অক্ষর-রূপ পাশাপাশি দেখায়:

rm -rf lab && mkdir lab && cd lab
show() { stat -c '%a  %A  %n' "$@"; }
touch report.txt script.sh secret.txt
echo "-- new files (umask $(umask)):"; show report.txt
chmod u+x,g-r,o= report.txt        # symbolic: + adds, - removes, = sets exactly
echo "-- after chmod u+x,g-r,o= :"; show report.txt
chmod 754 script.sh                # 7=rwx 5=r-x 4=r--
chmod 640 secret.txt               # 6=rw- 4=r-- 0=---
echo "-- octal 754 and 640:"; show script.sh secret.txt
chmod a-w secret.txt               # a = all three classes
echo "-- after chmod a-w:"; show secret.txt
mkdir shared public
chmod 2775 shared                  # 2 = setgid on a directory
chmod 1777 public                  # 1 = sticky bit, like /tmp
echo "-- special bits on directories:"; show shared public /tmp
chmod u+s script.sh                # setuid where owner has x -> s
chmod u-x,u+s report.txt           # setuid where owner has no x -> S
echo "-- setuid: s (with x) vs S (without x):"; show script.sh report.txt
echo "-- the same, as ls -l shows it:"
ls -l script.sh report.txt | cut -c1-10

-- new files (umask 0022):
644  -rw-r--r--  report.txt
-- after chmod u+x,g-r,o= :
700  -rwx------  report.txt
-- octal 754 and 640:
754  -rwxr-xr--  script.sh
640  -rw-r-----  secret.txt
-- after chmod a-w:
440  -r--r-----  secret.txt
-- special bits on directories:
2775  drwxrwsr-x  shared
1777  drwxrwxrwt  public
1777  drwxrwxrwt  /tmp
-- setuid: s (with x) vs S (without x):
4754  -rwsr-xr--  script.sh
4600  -rwS------  report.txt
-- the same, as ls -l shows it:
-rwS------
-rwsr-xr--

মালিক বদলানো — chown আর chgrp

chown rahim:accounts file একসাথে owner আর group বদলায়; chgrp accounts file শুধু group. নিয়মগুলো গুরুত্বপূর্ণ: Linux-এ একজন সাধারণ user নিজের ফাইলও অন্য কাউকে “দিয়ে দিতে” পারেন না — owner বদলানো শুধু root-এর (আরও নির্দিষ্টভাবে CAP_CHOWN ক্ষমতা যার আছে)। কারণ তা না হলে কেউ অন্যের নামে ফাইল রেখে disk quota এড়াতে পারত, বা অন্যের নামে ক্ষতিকর ফাইল রাখতে পারত। ফাইলের মালিক অবশ্য group বদলাতে পারেন, তবে শুধু সেই group-এ যার তিনি নিজে সদস্য। আর owner বা group বদলালে Linux সাধারণত setuid/setgid বিট মুছে দেয়, যাতে বদলানোর ফাঁকে কোনো বিশেষ ক্ষমতা অন্যের হাতে না যায়। পুরো একটি ফোল্ডারে প্রয়োগ করতে -R (recursive) — তবে অংশ ৯-এ দেখবেন, এই ছোট অক্ষরটি কত বড় দুর্ঘটনার উৎস।

৪ · Kernel কীভাবে সিদ্ধান্ত নেয় — permission-যাচাইয়ের নিয়ম

কোনো প্রসেস একটি ফাইল খুলতে (open), চালাতে (execve) বা path-এর একটি directory পেরোতে চাইলে kernel একটি সরল নিয়ম মানে। এখানে “আপনি” মানে প্রসেসের effective UID আর তার group-গুলো (অংশ ৬):

1. আপনার UID কি ফাইলের owner-এর UID? হ্যাঁ হলে শুধু owner-এর তিনটি বিট দেখা হয় — এখানেই শেষ।
2. না হলে: ফাইলের GID কি আপনার কোনো group-এর (প্রধান বা অতিরিক্ত) সাথে মেলে? হ্যাঁ হলে শুধু group-এর বিট.
3. না হলে: other-এর বিট.
4. যে শ্রেণি বাছা হলো, সেখানে চাওয়া প্রতিটি অধিকার (r, w বা x) থাকলে অনুমতি, একটিও না থাকলে EACCES — “Permission denied”.

খেয়াল করুন, শ্রেণিগুলো যোগ হয় না; প্রথম মিলটিই চূড়ান্ত। এর একটি অদ্ভুত ফল: owner-এর অধিকার group-এর চেয়ে কম হতে পারে, আর তখন মালিক নিজেই আটকে যান। Root-এর জন্য আলাদা নিয়ম, যা শেষ ধাপে দেখবেন। নিচের stepper-এ একটি ফাইল আর চারজন অনুরোধকারী:

একটি ফাইল খুলতে শুধু ফাইলটির অনুমতিই যথেষ্ট নয় — path-এর প্রতিটি directory-তে x লাগে। পর্ব ৪২-এর namei stepper-এ দেখেছেন, /home/rahim/docs/notes.txt খুলতে kernel /, /home, /home/rahim, docs — চারটিতে x যাচাই করে, তারপর ফাইলে r. তাই home directory 700 হলে ভেতরের কোনো ফাইল 644 হলেও অন্য user সেটি পড়তে পারবেন না; প্রথম দরজাতেই আটকে যাবেন।

static int acl_permission_check(struct inode *inode, int mask)
{
    unsigned int mode = inode->i_mode;

    if (uid_eq(current_fsuid(), inode->i_uid)) {   /* 1. owner? only owner bits */
        mode >>= 6;
    } else {
        if (IS_POSIXACL(inode) && (mode & S_IRWXG)) {
            int error = check_acl(inode, mask);      /* an ACL, if any, decides here */
            if (error != -EAGAIN)
                return error;
        }
        if (in_group_p(inode->i_gid))                /* 2. group member? group bits */
            mode >>= 3;
        /* 3. otherwise the lowest three bits: other */
    }
    if ((mask & ~mode & (MAY_READ | MAY_WRITE | MAY_EXEC)) == 0)
        return 0;                                    /* every wanted bit is present */
    return -EACCES;    /* generic_permission() then tries CAP_DAC_OVERRIDE etc. */
}

লক্ষ্য করুন mode >>= 6 আর mode >>= 3: owner-এর তিনটি বিট ৬ ঘর ডানে সরালে সবচেয়ে নিচের তিন ঘরে আসে, group-এর ৩ ঘর সরালে — তারপর একই mask & ~mode পরীক্ষা।

Directory-র অনুমতি হাতে-কলমে — x, w আর sticky bit

অংশ ২-এর টেবিলটি এবার পরীক্ষা করে দেখা যাক। নিচের কোড একটি box directory বানিয়ে তার mode বারবার বদলায়, আর প্রতিবার কয়েকটি কাজ চেষ্টা করে। try ফাংশনটি কমান্ড সফল হলে OK, ব্যর্থ হলে kernel-এর দেওয়া কারণ ছাপে। আমরা সবাই একই user (owner), তাই এখানে owner-এর বিটই কাজ করছে — কিন্তু নিয়ম group আর other-এর জন্যও একই।

rm -rf dl; mkdir dl && cd dl
mkdir box && echo "hello" > box/note.txt
try() {                         # run a command, print OK or the reason it failed
  printf '  %-26s' "$1"; shift
  if out=$("$@" 2>&1); then echo "OK ${out//$'\n'/ }"
  else err=${out%%$'\n'*}; echo "DENIED: ${err##*: }"; fi
}
mode() { echo "== box is $(stat -c '%A' box) ($1)"; }
chmod 600 box; mode "r and w, but no x"
try "ls box   (names only)" ls box
try "ls -l box (needs inodes)" ls -l box
try "cat box/note.txt" cat box/note.txt
try "cd box" cd box
chmod 100 box; mode "x only: traverse"
try "ls box" ls box
try "cat box/note.txt (known)" cat box/note.txt
chmod 200 box; mode "w without x"
try "touch box/new" touch box/new
chmod 300 box; mode "w and x"
try "touch box/new" touch box/new
chmod 500 box; mode "r and x, no w"
try "rm box/new" rm -f box/new
chmod 700 box; chmod 444 box/note.txt
echo "== note.txt is $(stat -c '%A' box/note.txt), box is $(stat -c '%A' box)"
try "rm read-only note.txt" rm -f box/note.txt
mkdir pub; chmod 1777 pub; touch pub/mine
echo "== pub is $(stat -c '%A' pub) (sticky, like /tmp)"
try "rm my own file in pub" rm pub/mine
chmod -R u+rwx box

== box is drw------- (r and w, but no x)
  ls box   (names only)     OK note.txt
  ls -l box (needs inodes)  DENIED: Permission denied
  cat box/note.txt          DENIED: Permission denied
  cd box                    DENIED: Permission denied
== box is d--x------ (x only: traverse)
  ls box                    DENIED: Permission denied
  cat box/note.txt (known)  OK hello
== box is d-w------- (w without x)
  touch box/new             DENIED: Permission denied
== box is d-wx------ (w and x)
  touch box/new             OK
== box is dr-x------ (r and x, no w)
  rm box/new                DENIED: Permission denied
== note.txt is -r--r--r--, box is drwx------
  rm read-only note.txt     OK
== pub is drwxrwxrwt (sticky, like /tmp)
  rm my own file in pub     OK 

৫ · umask — নতুন ফাইলের অনুমতি কে ঠিক করে

নতুন ফাইল তৈরির সময় প্রোগ্রাম open(path, O_CREAT, mode)-এ একটি mode চায়: সাধারণ ফাইলের জন্য প্রায় সব প্রোগ্রাম (editor, touch, shell redirection) চায় 0666, directory আর compiler-এর বানানো প্রোগ্রামের জন্য 0777. কিন্তু kernel সেটি হুবহু বসায় না — প্রসেসের umask-এ যে বিটগুলো ১, সেগুলো মুছে দেয়:

অর্থাৎ umask হলো একটি “ছাঁকনি” — যে বিট umask-এ আছে, নতুন ফাইলে তা থাকবে না। umask প্রসেসের একটি বৈশিষ্ট্য, child প্রসেস তা উত্তরাধিকারসূত্রে পায় (পর্ব ১০), আর umask কমান্ড shell-এর নিজেরটি দেখায় বা বদলায়। হিসাবটি binary-তে করলেই পরিষ্কার:

এবার একই হিসাব আসল kernel-এ — কয়েকটি umask-এ ফাইল আর directory বানিয়ে:

rm -rf um && mkdir um && cd um
echo "shell's umask now: $(umask)  (symbolic: $(umask -S))"
for m in 022 027 077 002; do
  ( umask "$m"                       # ( ) = subshell, so the change stays inside
    touch "f$m"; mkdir "d$m"
    printf 'umask %s -> new file %s   new dir %s\n' "$m" \
      "$(stat -c '%a %A' "f$m")" "$(stat -c '%a %A' "d$m")" )
done
echo "-- umask filters only at creation; a later chmod is not filtered:"
( umask 077; touch g; stat -c 'created: %a %A' g; chmod 644 g; stat -c 'chmod 644: %a %A' g )
echo "-- a program may ask for fewer bits (gcc asks 0777 for a.out, an editor 0666):"
( umask 022; printf 'int main(void){return 0;}\n' > t.c; gcc t.c -o t; stat -c '%a %A %n' t.c t )
echo "-- umask is inherited by child processes:"
( umask 027; bash -c 'echo "child bash sees umask $(umask)"' )

shell's umask now: 0022  (symbolic: u=rwx,g=rx,o=rx)
umask 022 -> new file 644 -rw-r--r--   new dir 755 drwxr-xr-x
umask 027 -> new file 640 -rw-r-----   new dir 750 drwxr-x---
umask 077 -> new file 600 -rw-------   new dir 700 drwx------
umask 002 -> new file 664 -rw-rw-r--   new dir 775 drwxrwxr-x
-- umask filters only at creation; a later chmod is not filtered:
created: 600 -rw-------
chmod 644: 644 -rw-r--r--
-- a program may ask for fewer bits (gcc asks 0777 for a.out, an editor 0666):
644 -rw-r--r-- t.c
755 -rwxr-xr-x t
-- umask is inherited by child processes:
child bash sees umask 0027

৬ · বিশেষ বিট — setuid, setgid, sticky আর তিন রকম UID

একটি ধাঁধা দিয়ে শুরু করি। পাসওয়ার্ড থাকে /etc/shadow-এ, যা শুধু root লিখতে পারে। অথচ যেকোনো সাধারণ user passwd কমান্ড দিয়ে নিজের পাসওয়ার্ড বদলাতে পারেন। কীভাবে? উত্তর হলো setuid বিট: /usr/bin/passwd ফাইলটির owner root, আর তার mode -rwsr-xr-x (4755). যে-ই এটি চালান, প্রোগ্রামটি চলার সময় ফাইলের মালিকের — অর্থাৎ root-এর — ক্ষমতা পায়।

এটি বুঝতে জানতে হবে, প্রতিটি প্রসেসের একটি নয়, তিনটি UID থাকে (GID-এরও তিনটি):

• Real UID — কে আসলে প্রসেসটি চালিয়েছেন। getuid() এটি দেয়।
• Effective UID — permission-যাচাইয়ে kernel কোনটি দেখবে। সাধারণত real-এর সমান; setuid প্রোগ্রাম exec করলে এটি ফাইলের owner হয়ে যায়। geteuid().
• Saved set-user-ID — exec-এর সময় effective UID-এর একটি কপি। প্রোগ্রাম সাময়িকভাবে ক্ষমতা ছেড়ে (seteuid(real)) পরে আবার ফিরে পেতে পারে, কারণ saved-এ পুরোনো মানটি আছে।

Linux-এ চতুর্থ একটি filesystem UID-ও আছে (সাধারণত effective-এর সমান) — /proc/self/status-এর Uid: লাইনে এই চারটি ক্রমে দেখা যায়: real, effective, saved, filesystem. এবার passwd চালানোর সময় তিনটি UID কীভাবে বদলায়, দেখুন:

setgid — ফাইলে আর directory-তে দুই কাজ

Setgid বিট (২০০০) ফাইলে setuid-এর মতোই, শুধু group-এর জন্য: প্রোগ্রাম ফাইলের group-এর effective GID নিয়ে চলে। নিচের আউটপুটে দেখবেন unix_chkpwd হলো -rwxr-sr-x root:shadow — সে root নয়, শুধু shadow group-এর ক্ষমতায় চলে, তাই /etc/shadow পড়তে পারে কিন্তু লিখতে পারে না। পূর্ণ root না দিয়ে শুধু দরকারি অংশটুকু দেওয়া — least privilege-এর সুন্দর উদাহরণ।

Directory-তে setgid-এর অর্থ সম্পূর্ণ আলাদা এবং অত্যন্ত কাজের: ভেতরে নতুন তৈরি প্রতিটি ফাইল তৈরিকারীর প্রধান group না পেয়ে directory-র group পায়, আর নতুন subdirectory-ও setgid বিট পায়। ধরুন একটি সফটওয়্যার ফার্মে /srv/project ফোল্ডারটি dev group-এর, mode 2775 (বা গোপন রাখতে 2770). rahim যে ফাইলই বানান, তার group হবে dev, তাই দলের সবাই পড়তে পারবেন; সাথে umask 002 হলে লিখতেও পারবেন। Setgid না থাকলে ফাইলটি rahim-এর ব্যক্তিগত group পেত, আর অন্যরা বারবার “Permission denied” দেখতেন।

sticky bit — shared directory-র রক্ষাকবচ

শুরুর দিকের Unix-এ sticky bit প্রোগ্রাম ফাইলে বসত: “এই প্রোগ্রামের কোড চলার পরও swap-এ রেখে দেওয়া হোক”, যাতে বারবার চালানো প্রোগ্রাম দ্রুত খোলে — নামটি সেখান থেকে। আধুনিক Linux ফাইলে এই বিট উপেক্ষা করে। Directory-তে এর অর্থ অংশ ৪-এ দেখেছেন: ভেতরের ফাইল মুছতে বা নাম বদলাতে পারবেন শুধু ফাইলের owner, directory-র owner বা root. /tmp আর /var/tmp এজন্যই 1777.

নিজের পরিচয় দেখা আর setuid প্রোগ্রামের নিরীক্ষা

এবার এই পাতার sandbox-এ নিজের পরিচয়, account ফাইলগুলোর অনুমতি, setuid-এর কাজ আর একটি প্রতিরক্ষামূলক নিরীক্ষা — সিস্টেমে কোন কোন setuid/setgid প্রোগ্রাম আছে — একসাথে দেখা যাক:

echo "== who am I?"; id; echo "whoami: $(whoami)   groups: $(groups)"
echo "== this process: Uid/Gid = real effective saved filesystem"
grep -E '^(Uid|Gid):' /proc/self/status
echo "== my line in /etc/passwd (name:x:UID:GID:comment:home:shell)"
grep "^$(whoami):" /etc/passwd
echo "== who may read the account files?"
stat -c '%A %U:%G %n' /etc/passwd /etc/group /etc/shadow
if cat /etc/shadow > /dev/null 2>&1; then echo "shadow is readable?! fix it"
else echo "cat /etc/shadow -> Permission denied (as it should be)"; fi
echo "== yet the setuid-root passwd program may read it on my behalf"
stat -c '%A %U %n' /usr/bin/passwd
passwd -S "$(whoami)"
echo "== audit: setuid/setgid programs on this system"
find /usr/bin /usr/sbin -xdev -type f \( -perm -4000 -o -perm -2000 \) 2>/dev/null |
  sort | xargs stat -c '%A %U:%G %n'
echo "== can I use sudo?"
if command -v sudo > /dev/null 2>&1; then sudo -n -l 2>&1 | head -5
else echo "sudo is not installed in this sandbox - nothing to elevate to"; fi
echo "== my Linux capabilities (hex bitmask; 0 = none):"
grep -E '^Cap(Prm|Eff)' /proc/self/status

== who am I?
uid=999(wandbox) gid=999(wandbox) groups=999(wandbox)
whoami: wandbox   groups: wandbox
== this process: Uid/Gid = real effective saved filesystem
Uid:	999	999	999	999
Gid:	999	999	999	999
== my line in /etc/passwd (name:x:UID:GID:comment:home:shell)
wandbox:x:999:999::/home/wandbox:/bin/sh
== who may read the account files?
-rw-r--r-- root:root /etc/passwd
-rw-r--r-- root:root /etc/group
-rw-r----- root:shadow /etc/shadow
cat /etc/shadow -> Permission denied (as it should be)
== yet the setuid-root passwd program may read it on my behalf
-rwsr-xr-x root /usr/bin/passwd
wandbox L 2025-12-24 -1 -1 -1 -1
== audit: setuid/setgid programs on this system
-rwxr-sr-x root:shadow /usr/bin/chage
-rwsr-xr-x root:root /usr/bin/chfn
-rwsr-xr-x root:root /usr/bin/chsh
-rwxr-sr-x root:shadow /usr/bin/expiry
-rwsr-xr-x root:root /usr/bin/gpasswd
-rwsr-xr-x root:root /usr/bin/mount
-rwsr-xr-x root:root /usr/bin/newgrp
-rwsr-xr-x root:root /usr/bin/passwd
-rwsr-xr-x root:root /usr/bin/su
-rwsr-xr-x root:root /usr/bin/umount
-rwxr-sr-x root:shadow /usr/sbin/pam_extrausers_chkpwd
-rwxr-sr-x root:shadow /usr/sbin/unix_chkpwd
== can I use sudo?
sudo is not installed in this sandbox - nothing to elevate to
== my Linux capabilities (hex bitmask; 0 = none):
CapPrm:	0000000000000000
CapEff:	0000000000000000

setuid কেন ঝুঁকিপূর্ণ, আর কীভাবে পাহারা দেবেন

একটি setuid-root প্রোগ্রাম মানে সাধারণ user-এর দেওয়া ইনপুট — আর্গুমেন্ট, environment variable, ফাইলের নাম — root-এর ক্ষমতায় চলা কোডে ঢুকছে। সেই কোডে একটি বাগ মানে সাধারণ user root হয়ে যাওয়ার পথ। ইতিহাসে এমন বহু ঘটনা আছে; যেমন ২০২২ সালের শুরুতে প্রকাশিত “PwnKit” (CVE-2021-4034) — polkit-এর setuid প্রোগ্রাম pkexec-এ একটি ত্রুটি, যা বহু বছর ধরে প্রায় সব বড় distro-তে ছিল। শিক্ষা একটাই: setuid প্রোগ্রাম যত কম, আক্রমণের জায়গা তত কম। প্রতিরক্ষার অভ্যাসগুলো:

• নিয়মিত তালিকা নিন: find / -xdev -type f -perm -4000 -ls 2>/dev/null (setgid-এর জন্য -perm -2000), ফলাফল সংরক্ষণ করে পরের বারের সাথে মেলান — নতুন অচেনা setuid ফাইল মানে তদন্ত
• প্রতিটি ফাইল কোন package-এর, যাচাই করুন (Debian/Ubuntu-তে dpkg -S, Fedora/RHEL-এ rpm -qf); package-এর বাইরের setuid ফাইল সন্দেহজনক
• যেখানে প্রোগ্রাম চালানোর দরকার নেই (/tmp, /home, USB, backup disk), সেখানে nosuid (আর দরকারে noexec, nodev) দিয়ে mount করুন
• দরকার না থাকলে setuid সরান (chmod u-s) বা প্রোগ্রামটিই বাদ দিন; পূর্ণ root-এর বদলে capability ব্যবহার করুন (অংশ ৮) — কিছু distro ping-এর মতো প্রোগ্রাম থেকে setuid সরিয়ে এভাবেই ঝুঁকি কমিয়েছে
• নিজে কখনো script বা নিজের লেখা প্রোগ্রামে chmod 4755 দিয়ে root-ক্ষমতা দেবেন না; প্রয়োজনে নির্দিষ্ট কমান্ডের sudo নিয়ম লিখুন (অংশ ৭)

৭ · sudo আর su — কখন, কীভাবে, কতটুকু ক্ষমতা

প্রশাসনের কাজ — প্যাকেজ ইনস্টল, সার্ভিস restart, অন্যের ফাইল ঠিক করা — root ছাড়া হয় না। দুটি পথ:

Ubuntu-র মতো অনেক distro-তে root-এর কোনো ব্যবহারযোগ্য পাসওয়ার্ডই থাকে না; প্রথম user sudo group-এ থাকেন (Fedora/RHEL-এ সমতুল্য group wheel). sudo পাসওয়ার্ড একবার যাচাই করার পর কিছুক্ষণ মনে রাখে (মূল sudo-র ডিফল্ট ৫ মিনিট; কিছু distro-তে বেশি, যেমন Ubuntu-তে ১৫ মিনিট বলে প্রচলিত; নীতিতে timestamp_timeout দিয়ে বদলানো যায়)। sudo -l দেখায় আপনাকে কী কী অনুমতি দেওয়া আছে — অচেনা সার্ভারে ঢুকে প্রথমেই এটি দেখা ভালো অভ্যাস।

sudoers — নীতি লেখা, visudo দিয়ে

নীতি থাকে /etc/sudoers আর /etc/sudoers.d/-এর ফাইলগুলোতে। এগুলো কখনো সাধারণ editor-এ খুলবেন না — সবসময় visudo (বা visudo -f /etc/sudoers.d/ফাইল)। visudo ফাইলটি lock করে, সংরক্ষণের আগে ব্যাকরণ যাচাই করে, আর ভুল থাকলে সতর্ক করে — কারণ sudoers-এ একটি ভুল মানে কেউ আর sudo ব্যবহার করতে পারবেন না, আর root পাসওয়ার্ড না থাকলে নিজের সার্ভার থেকে নিজেই বাইরে।

# Format:  WHO   HOST=(RUN-AS)   COMMANDS
# Full admin (on Ubuntu this line already exists for the sudo group):
%sudo      ALL=(ALL:ALL) ALL

# Least privilege: the web team may only restart or reload nginx, nothing else.
%webteam   ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx

# A deploy account may run exactly one script as the app user (not root), no password.
deploy     ALL=(appuser) NOPASSWD: /opt/app/bin/deploy.sh

# Let editors open the config safely: sudoedit runs the editor as YOU on a temp copy.
%webteam   ALL=(root) sudoedit /etc/nginx/sites-available/*

নিয়ম লেখার সময় তিনটি ফাঁদ মনে রাখুন। (১) কমান্ডের পুরো path দিন (/usr/bin/systemctl), শুধু নাম নয়। (২) Shell-এ বেরোনো যায় এমন প্রোগ্রাম — editor (vim, nano), pager (less), find, tar, script-ভাষার interpreter — sudo-তে দিলে কার্যত পুরো root দেওয়া হয়ে যায়, কারণ এগুলোর ভেতর থেকে অন্য কমান্ড চালানো যায়; ফাইল সম্পাদনার জন্য sudoedit ব্যবহার করুন। (৩) Wildcard আর লেখা-যায় এমন script সাবধানে: deploy.sh যদি deploy user নিজেই বদলাতে পারেন, তাহলে নিয়মটি “যেকোনো কিছু চালানো যাবে” হয়ে গেল — script-টি root-এর মালিকানায়, 755 রাখুন। এবার দুটি নমুনা আউটপুট:

$ sudo -l
User rahim may run the following commands on web01:
    (root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx
    (root) sudoedit /etc/nginx/sites-available/*

$ sudo systemctl restart nginx          # allowed, and logged
$ sudo bash
Sorry, user rahim is not allowed to execute '/usr/bin/bash' as root on web01.

$ sudo grep sudo /var/log/auth.log | tail -2      # (RHEL: /var/log/secure, or journalctl)
... sudo:    rahim : TTY=pts/0 ; PWD=/home/rahim ; USER=root ; COMMAND=/usr/bin/systemctl restart nginx
... sudo:    rahim : command not allowed ; TTY=pts/0 ; PWD=/home/rahim ; USER=root ; COMMAND=/usr/bin/bash

কেন সব কাজ root হিসেবে নয়

“প্রতিবার sudo লেখা বিরক্তিকর, root হয়েই থাকি” — এই অভ্যাসের তিনটি দাম। প্রথমত, ভুলের ক্ষতি অসীম: একটি ভুল জায়গায় স্পেস দেওয়া rm -rf সাধারণ user-এ নিজের কিছু ফাইল মোছে, root-এ পুরো সিস্টেম। দ্বিতীয়ত, প্রতিটি প্রোগ্রাম root-এর ক্ষমতা পায়: ব্রাউজার, ইন্টারনেট থেকে নামানো script, AI-এর দেওয়া কমান্ড — যেকোনো একটিতে ক্ষতিকর কিছু থাকলে সে আর কোনো বাধা পায় না। তৃতীয়ত, জবাবদিহি হারায়: লগে শুধু “root” দেখা যায়। এজন্যই নীতিটির নাম least privilege — প্রতিটি মানুষ ও প্রোগ্রাম ঠিক ততটুকু ক্ষমতা পাবে, যতটুকু তার কাজের জন্য দরকার, আর ঠিক ততক্ষণ।

৮ · Root-কে টুকরো করা, ACL আর অন্য OS-এর মডেল

Linux capability — পুরো মাস্টার চাবি নয়, একটি চাবি

পুরোনো Unix-এ ক্ষমতা ছিল দুই রকম: UID 0 হলে সব, না হলে প্রায় কিছুই নয়। Linux ২.২ (১৯৯৯) থেকে root-এর ক্ষমতাকে কয়েক ডজন আলাদা টুকরোয় ভাগ করেছে, যাদের বলে Linux capability: CAP_NET_BIND_SERVICE (১০২৪-এর নিচের port খোলা), CAP_CHOWN, CAP_DAC_OVERRIDE (ফাইলের অনুমতি উপেক্ষা), CAP_SYS_ADMIN (অনেক কিছুর মিশ্রণ — প্রায় root-এর সমান, এড়িয়ে চলুন) ইত্যাদি। নাম এক হলেও এটি পর্ব ৪৬-এর তাত্ত্বিক “capability list” (প্রতিটি বস্তুর জন্য টিকিট) থেকে আলাদা জিনিস — Linux-এরটি আসলে root-এর বিশেষ অধিকারের ভাগ।

সবচেয়ে পরিচিত প্রয়োজন: একটি Node.js বা Go ওয়েব সার্ভারকে port 80-এ চালানো। Linux-এ ১০২৪-এর নিচের port খুলতে বিশেষ অধিকার লাগে, তাই অনেকে পুরো সার্ভারটিই root হিসেবে চালান — তখন সার্ভারের একটি বাগ মানে পুরো মেশিন। নিরাপদ বিকল্পগুলো:

$ sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/myserver
$ getcap /usr/local/bin/myserver
/usr/local/bin/myserver cap_net_bind_service=ep
# now an ordinary user (e.g. "web") can run it and bind port 80 - nothing more

# with systemd, prefer giving the capability to the service instead of the file:
#   [Service]
#   User=web
#   AmbientCapabilities=CAP_NET_BIND_SERVICE
#   CapabilityBoundingSet=CAP_NET_BIND_SERVICE
#   NoNewPrivileges=yes

ফাইলের capability থাকে ফাইলের extended attribute-এ, আর getcap -r / দিয়ে setuid-এর মতোই নিরীক্ষা করা যায় (এই পাতার sandbox-এ getcap -r /usr/bin /usr/sbin কিছুই দেখায়নি)। আরেকটি বিকল্প হলো reverse proxy (nginx port 80-এ, আপনার অ্যাপ 8080-এ), বা net.ipv4.ip_unprivileged_port_start sysctl দিয়ে সীমাটিই নামানো। Capability তত্ত্বের সাথে কীভাবে মেলে, তা পর্ব ৪৬-এ; আর seccomp, SELinux দিয়ে প্রোগ্রামকে আরও বেঁধে রাখার কথা পর্ব ৪৯-এ।

POSIX ACL — তিন শ্রেণির বাইরে একজনকে অনুমতি

তিন শ্রেণির মডেলের সীমা: ফাইলটি accounts group-এর, কিন্তু অডিট বিভাগের শুধু sumi-কে পড়ার অনুমতি দিতে চান — sumi-কে accounts-এ ঢোকালে তিনি সব ফাইলে লেখার অধিকার পেয়ে যাবেন। সমাধান ACL (access control list), পর্ব ৪৬-এর access matrix-এর “কলাম” ধরে রাখা রূপ:

$ setfacl -m u:sumi:r salary.xlsx        # one extra user, read only
$ ls -l salary.xlsx
-rw-rw----+ 1 rahim accounts 18230 Oct 26 10:02 salary.xlsx     # "+" = an ACL exists
$ getfacl salary.xlsx
# file: salary.xlsx
# owner: rahim
# group: accounts
user::rw-
user:sumi:r--
group::rw-
mask::rw-
other::---
$ setfacl -d -m g:dev:rwX /srv/project   # default ACL: inherited by new files

ACL থাকলে ls -l-এর শেষে + চিহ্ন আসে — এটি দেখলে মনে রাখবেন, ৯টি বিটই পুরো গল্প নয়। mask হলো নামধারী user আর group-এর সর্বোচ্চ সীমা, আর ACL-যুক্ত ফাইলে chmod g=… আসলে mask বদলায়। ACL বেশিরভাগ Linux file system (ext4, XFS, Btrfs) সমর্থন করে; ভেতরের তত্ত্ব আর capability-র সাথে তুলনা পর্ব ৪৬-এ।

Windows আর macOS-এর সাথে তুলনা

Windows-এর মডেল শুরু থেকেই ভিন্ন। NTFS-এর প্রতিটি ফাইল ও ফোল্ডারে একটি পূর্ণ ACL (DACL) থাকে: অনেকগুলো entry (ACE), প্রতিটিতে একটি user বা group-এর পরিচয় (SID, যেমন S-1-5-32-544 = Administrators) আর অনুমতি — Full control, Modify, Read & execute ইত্যাদি, অনুমতি দেওয়া (Allow) বা স্পষ্টভাবে নিষেধ (Deny). মা-ফোল্ডার থেকে অনুমতি উত্তরাধিকারসূত্রে আসে। অর্থাৎ Linux-এর ৯ বিট + ঐচ্ছিক ACL-এর বদলে Windows-এ ACL-ই প্রধান মডেল।

PS C:\> icacls C:\Data\salary.xlsx
C:\Data\salary.xlsx BUILTIN\Administrators:(I)(F)
                    NT AUTHORITY\SYSTEM:(I)(F)
                    DHAKA-PC\rahim:(I)(M)
                    BUILTIN\Users:(I)(RX)
Successfully processed 1 files; Failed processing 0 files
# (I) = inherited from the parent folder, F = full, M = modify, RX = read & execute

Root-এর সমতুল্য Administrators group, আর তার চেয়েও বেশি ক্ষমতার SYSTEM account. sudo-র কাছাকাছি ধারণা হলো UAC (User Account Control, Windows Vista থেকে): Administrators-এর সদস্য হলেও আপনার প্রোগ্রাম সাধারণত একটি “ছাঁটা” token নিয়ে, সাধারণ user-এর অধিকারে চলে; কোনো কাজে পূর্ণ অধিকার লাগলে পর্দা অন্ধকার করে “Do you want to allow this app to make changes?” জিজ্ঞাসা আসে, তারপর শুধু সেই প্রোগ্রামটি পূর্ণ token পায়। পার্থক্যও আছে: sudo একটি স্পষ্ট নীতি-ফাইল আর প্রতি-কমান্ড লগ দিয়ে চলে, UAC মূলত একটি সম্মতির ধাপ, আর Microsoft নিজেও UAC-কে কঠোর নিরাপত্তা-সীমানা হিসেবে নয় বরং সুবিধা ও সতর্কতার ব্যবস্থা হিসেবে বর্ণনা করেছে বলে জানা যায়। Windows-এ setuid-এর সরাসরি সমতুল্য নেই; বিশেষ ক্ষমতার কাজ সাধারণত একটি সার্ভিস (SYSTEM হিসেবে চলে) করে দেয়।

macOS Unix-ভিত্তিক, তাই ls -l, chmod, setuid, sudo — সব এই পর্বের মতোই, সাথে NFSv4 ধাঁচের ACL (ls -le দিয়ে দেখা যায়)। তার ওপর System Integrity Protection (SIP) নামের একটি স্তর আছে, যা কিছু সিস্টেম ফোল্ডার root-এর কাছ থেকেও রক্ষা করে — অর্থাৎ সেখানে “root মানেই সব” আর সত্য নয়, যে ধারণা পর্ব ৪৯-এর mandatory access control-এর সাথে মেলে।

৯ · সাধারণ ভুল আর তাদের নিরাপদ সমাধান

SSH-এর বিষয়টি একটু খুলে বলি। OpenSSH সার্ভারের sshd_config-এ StrictModes নামের option ডিফল্টে yes থাকে: login গ্রহণের আগে sshd user-এর home, ~/.ssh আর authorized_keys-এর মালিকানা আর অনুমতি দেখে, আর অন্যদের লেখার মতো হলে key-ভিত্তিক login প্রত্যাখ্যান করে — ঠিক কোন অনুমতিতে আপত্তি করবে তা সংস্করণ-ভেদে সামান্য আলাদা হতে পারে, আর কারণটি সার্ভারের লগে (যেমন Authentication refused: bad ownership or modes) লেখা থাকে। Client দিকেও ssh খুব খোলা private key ব্যবহার করতে অস্বীকার করে: “WARNING: UNPROTECTED PRIVATE KEY FILE! … Permissions 0644 … are too open.” তখন StrictModes বন্ধ করা নয়, অনুমতি ঠিক করাই সমাধান।

নিরাপদে ঠিক করার ধাপ

কেউ একটি ফোল্ডারে ভুল করে chmod -R 777 চালিয়ে ফেললে আবার -R দিয়ে একটি সংখ্যা বসানো আরেকটি ভুল — কারণ ফাইল আর directory-র দরকার আলাদা (ফাইলে x চাই না, directory-তে চাই)। নিরাপদ পদ্ধতি: আগে দেখুন (find dir -perm -0002 | head), তারপর আলাদা করে ঠিক করুন:

$ sudo chown -R deploy:www-data /var/www/shop
$ sudo find /var/www/shop -type d -exec chmod 750 {} +    # directories: rwxr-x---
$ sudo find /var/www/shop -type f -exec chmod 640 {} +    # files: rw-r-----
$ sudo chmod 2770 /var/www/shop/uploads                   # only here may the server write
$ sudo find /var/www/shop -perm -0002                     # verify: should print nothing

অথবা symbolic রূপের একটি সুন্দর কৌশল: chmod -R u=rwX,g=rX,o= dir — বড় হাতের X মানে “শুধু directory-তে, বা আগে থেকে কারও x আছে এমন ফাইলে x দেওয়া হবে।” প্রতিটি পরিবর্তনের পর যাচাই করুন, আর বড় পরিবর্তনের আগে getfacl -R dir > perms.bak দিয়ে বর্তমান অবস্থা সংরক্ষণ করে রাখুন — দরকারে setfacl --restore=perms.bak.

১০ · AI-এর যুগে permission — দ্রুত সমাধানের ফাঁদ

“Permission denied” হলো এমন একটি error, যেখানে AI সবচেয়ে বেশি বিপজ্জনক “সমাধান” দেয় — কারণ chmod 777 বা sudo প্রায় সবসময় error-টি সরিয়ে দেয়, আর AI-এর লক্ষ্য প্রায়ই error সরানো, নিরাপত্তা নয়। আপনার কাজ হলো প্রশ্নটি এমনভাবে করা, যাতে উত্তর কারণ খোঁজে, আর উত্তর নিজে যাচাই করা।

AI-এর দেওয়া permission-পরামর্শ চালানোর আগে — চেকলিস্ট

• কমান্ডে 777, -R, sudo, chown root বা u+s থাকলে থেমে কারণ জিজ্ঞেস করেছি, আর কম-ক্ষমতার বিকল্প চেয়েছি
• প্রসেসটি কোন user হিসেবে চলে (ps -o user,comm) আর path-এর প্রতিটি directory-র অনুমতি (namei -l path) নিজে দেখেছি
• octal আর umask-এর হিসাব binary-তে নিজে মিলিয়েছি, আর একটি পরীক্ষা-ফোল্ডারে আগে চালিয়ে দেখেছি
• আমার distro, init system আর সংস্করণের সাথে কমান্ড মেলে কি না দেখেছি; সন্দেহ হলে man chmod, man sudoers, man 7 capabilities পড়েছি
• পরিবর্তনের আগে বর্তমান অনুমতি সংরক্ষণ করেছি, আর পরে find -perm -0002 ও setuid-নিরীক্ষা দিয়ে নিশ্চিত হয়েছি যে নতুন ছিদ্র তৈরি হয়নি