drwxr-xr-x-এর অর্থ কী? Linux permission 755 ব্যাখ্যা
drwxr-xr-x-এর 10টি অক্ষর একে একে পড়ে কীভাবে 755 হয় তা জানুন। directory-তে x কেন traverse বোঝায় এবং chmod 777 কেন সঠিক সমাধান নয়, দেখুন।
drwxr-xr-x-এর অর্থ
drwxr-xr-x এমন একটি directory বোঝায়, যা এর owner পরিবর্তন করতে পারেন এবং অন্য সব user কোনো কিছু পরিবর্তন না করেই পড়তে ও এর মধ্য দিয়ে প্রবেশ করতে পারেন। Octal-এ এই mode হলো 755। Linux-এর ls -l output-এর প্রতিটি line-এর শুরুতে এই দশটি character থাকে। এগুলোর অর্থ ও ক্রম সব সময় একই থাকে। তাই একটি string শিখলেই সবগুলো বোঝা যায়।
বাকি নিয়মের আগে একটি নিয়ম বুঝতে হবে। কারণ আপনার নিজের testing থেকে কোনো তথ্য পাওয়া যাবে কি না, এটি সেই বিষয়টি নির্ধারণ করে। root user permission bit উপেক্ষা করেন। Kernel root-কে CAP_DAC_OVERRIDE capability (discretionary access control override) দেয়। তাই mode-এ নিষেধ থাকলেও root file খুলতে পারেন। এই page-এর প্রতিটি example root user-এর ক্ষেত্রে সফল হবে, bit-এ যা-ই লেখা থাকুক। নিয়মগুলো কার্যকর হতে দেখতে চাইলে normal user হিসেবে login করুন।
দশটি অক্ষর, একবারে একটি
দেখার জন্য একটি directory এবং একটি file তৈরি করুন। এখানে নতুন directory-এর বাইরে কোনো কিছুর পরিবর্তন হবে না।
mkdir -p ~/permdemo/inner
printf 'hello\n' > ~/permdemo/inner/notes.txt
ls -ld ~/permdemo ~/permdemo/inner ~/permdemo/inner/notes.txtসাধারণ default umask 022 হলে, directory-এর দুটি লাইনের শুরু হয় drwxr-xr-x দিয়ে এবং file-এর লাইন শুরু হয় -rw-r--r-- দিয়ে।
Character 1 হলো file type, permission নয়। d হলো directory। - হলো regular file। l হলো symbolic link। c এবং b হলো character ও block device node। s হলো socket এবং p হলো named pipe। এটি octal value-এর বাইরে থাকে। তাই drwxr-xr-x-এর মান 755 হয়, d দিয়ে শুরু হয় না।
এর পরের নয়টি character তিনটি করে তিনটি group-এ বিভক্ত। এগুলোর ক্রম কখনো বদলায় না।
- Character 2 থেকে 4 হলো owner triad। এগুলো file-এর মালিক user-এর ক্ষেত্রে প্রযোজ্য bit।
- Character 5 থেকে 7 হলো group triad। এগুলো file-এর group-এর ক্ষেত্রে প্রযোজ্য bit।
- Character 8 থেকে 10 হলো other triad। এগুলো অন্য সব user-এর ক্ষেত্রে প্রযোজ্য bit।
একটি triad-এর slot-এর ক্রম সবসময় r, তারপর w, তারপর x। Dash থাকলে সেই bit সক্রিয় নয়। অক্ষরগুলোর অবস্থান কখনো বদলায় না। r-x মানে read আছে, write নেই। -w- মানে write আছে, read নেই; এটি বৈধ হলেও বিরল।
তাই drwxr-xr-x এভাবে বিভক্ত হয়: directory-এর জন্য d, তারপর owner-এর জন্য rwx, group-এর জন্য r-x এবং other-এর জন্য r-x।
কিছু system-এ একাদশ character দেখা যায়। শেষের dot, drwxr-xr-x., মানে file-এ একটি SELinux (security enhanced Linux) context আছে। Fedora এবং Rocky-এর মতো SELinux distribution-এ এটি default হিসেবে দেখা যায়। শেষের plus, drwxr-xr-x+, মানে file-এ একটি POSIX ACL (access control list) আছে। এটি এই নয়টি bit-এর অতিরিক্ত rule-এর একটি set। অতিরিক্ত rule দেখতে getfacl <path> ব্যবহার করুন।
ডিরেক্টরিতে r, w এবং x ভিন্ন কাজ করে
এটি নতুন ব্যবহারকারীরা যে প্রথম নিয়মটি ভুল বোঝেন। ফাইল এবং ডিরেক্টরি উভয়ের ক্ষেত্রেই অক্ষরগুলো একই। কিন্তু এগুলো যে অধিকার দেয়, তা এক নয়।
- ফাইলে
rথাকলে তার বিষয়বস্তু পড়া যায়। ডিরেক্টরিতেrথাকলে তার ভেতরের নামগুলোর তালিকা দেখা যায়; সাধারণত plainls-এর জন্য এটিই প্রয়োজন। - ফাইলে
wথাকলে তার বিষয়বস্তু পরিবর্তন করা যায়। ডিরেক্টরিতেwথাকলে তার ভেতরে entry যোগ ও অপসারণ করা যায়। কোনো ফাইল মুছে ফেলা ডিরেক্টরির একটি পরিবর্তন। তাই এটি নির্ধারণ করে ডিরেক্টরির write permission; ফাইলটির নিজস্ব mode এখানে কোনো ভূমিকা রাখে না। - ফাইলে
xথাকলে সেটিকে program হিসেবে চালানো যায়। ডিরেক্টরিতেxথাকলে সেটি traverse করা যায়। অর্থাৎ path lookup-এর সময় kernel ওই ডিরেক্টরির ভেতরের কোনো নাম resolve করতে পারে।
Traverse বিষয়টি অনেককে বিস্মিত করে। ডিরেক্টরিতে x থাকলে কোনো কিছু execute হয় না। /srv/site/index.html খোলার জন্য প্রথমে /-এ x, এরপর /srv-এ x, তারপর /srv/site-এ x এবং শেষে ফাইলে r প্রয়োজন। ওই path-এর কোনো একটি ডিরেক্টরিতে আপনার জন্য x না থাকলে lookup সেখানেই থেমে যায়। ফাইলটির শেষে world-readable permission থাকলেও caller-কে পুরো path-এর জন্য Permission denied জানানো হয়। namei -l /srv/site/index.html mode ও owner-সহ path-এর প্রতিটি ধাপ দেখায়। ফলে কোন অংশে lookup থামছে, তা বোঝা যায়।
r আছে কিন্তু x নেই—এমন ডিরেক্টরি একটি অস্বাভাবিক আংশিক অবস্থা। listing-এর অধিকার r দেয় বলে সাধারণ user নামগুলোর তালিকা দেখতে পারে। কিন্তু কোনো entry-র stat তথ্য দেখা যায় না। তাই ls -l size ও mode column-এ question mark বসায় এবং প্রতিটির জন্য ls: cannot access ...: Permission denied দেখায়।
অক্ষর থেকে 755
প্রতিটি triad হলো তিন বিটের একটি সংখ্যা। r হলো 4, w হলো 2 এবং x হলো 1। চালু থাকা বিটগুলোর মান যোগ করুন।
rwxহলো 4 + 2 + 1 = 7rw-হলো 4 + 2 = 6r-xহলো 4 + 1 = 5r--হলো 4---হলো 0
তাই drwxr-xr-x-এর মান owner-এর জন্য 7, group-এর জন্য 5 এবং অন্যদের জন্য 5: 755। -rw-r--r-- হলো 6, 4, 4: 644। drwxrwxr-x হলো 7, 7, 5: 775, যা group-এর জন্য write permission যোগ করা 755। অক্ষর হাতে গুনতে হয় না, কারণ stat একই সঙ্গে উভয় রূপ দেখায়।
stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt%A হলো অক্ষরের রূপ, %a হলো octal রূপ, এবং %U ও %G owning user ও owning group-এর নাম নির্দেশ করে।
যে permission string-গুলো মানুষ খোঁজে
বাস্তব সার্ভারে সাধারণত এই mode-গুলো দেখা যায়। এখানে প্রতিটির octal value এবং কোন ক্ষেত্রে এটি ব্যবহৃত হয় তা দেওয়া হলো।
-rw-r--r--হলো 644। কোনো service যে সাধারণ file শুধু পড়ে, যেমন configuration file বা HTML page।-rw-------হলো 600। গোপন তথ্যের জন্য: একটি SSH private key বা কোনো application-এর.envfile।-rw-rw-r--হলো 664। কোনো group-shared directory-র file, যেখানে দলের সদস্যদের write access প্রয়োজন।-rwxr-xr-xহলো 755। Script ও binary, যেমন/usr/local/bin/backup.shএবং অধিকাংশ/usr/bin।-rwx------হলো 700। Private script, যা শুধু তার owner চালাতে পারে।drwxr-xr-xহলো 755। প্রায় সব system directory এবং কোনো website-এর document root।drwx------হলো 700।~/.sshএবং নিরাপত্তা-সীমিত server-এর home directory।drwxrwxr-xহলো 775। এমন directory, যেখানে owner-এর group write করতে পারে।drwxrwsr-xহলো 2775। একই permission-এর সঙ্গে setgid bit থাকে, তাই ভেতরে তৈরি নতুন file-গুলো directory-র group inherit করে।drwxrwxrwtহলো 1777।/tmp। শেষেরtহলো sticky bit, তাই কোনো user শুধু নিজের file মুছতে পারে।-rwsr-xr-xহলো 4755। এমন setuid binary, যা তার owner-এর account হিসেবে চলে, যেমন/usr/bin/passwdএবং/usr/bin/sudo।-rw-rw-rw-হলো 666 এবংdrwxrwxrwxহলো 777। এগুলো world-writable; server-এ এটি প্রায় সব সময়ই ভুল configuration।lrwxrwxrwxহলো প্রতিটি symbolic link-এর ক্ষেত্রে প্রদর্শিত mode। Linux link-এর mode bit উপেক্ষা করে এবং target পরীক্ষা করে। তাই এই string-এর নিজস্ব কোনো অর্থ নেই।
আপনার জন্য কোন triad প্রযোজ্য
এখানেই beginners-রা দ্বিতীয় যে নিয়মটি ভুল বোঝে। kernel ঠিক একটি triad বেছে নেয় এবং সেখানেই থামে।
আপনার user ID যদি file-এর owner-এর সঙ্গে মেলে, তাহলে আপনি owner triad পাবেন। group এবং other bits আর পরীক্ষা করা হবে না। তা না হলে file-এর group যদি আপনার কোনো group-এর সঙ্গে মেলে, তাহলে আপনি group triad পাবেন। অন্যথায় আপনি other triad পাবেন।
এর দুটি ফল আছে। সবচেয়ে restrictive হলেও owner triad-ই প্রযোজ্য হয়। mode 0466-এর একটি file, যা -r--rw-rw- হিসেবে দেখানো হয়, তার owner-কে শুধু read করতে দেয়, কিন্তু অন্য সবাই write করতে পারে। কারণ owner check প্রথমেই মিলে গেছে এবং এর পরে আর কিছু পরীক্ষা করা হয়নি। এটি বৈধ আচরণ, তবে প্রথমবার দেখলে সবাই বিভ্রান্ত হয়।
এরপর group triad নির্ধারিত হয় file-এর group দিয়ে, আপনি কোন কোন group-এর সদস্য সেই তালিকা দিয়ে নয়। ls -l প্রতিটি লাইনে দুটি name দেখায়: প্রথমে owner, তারপর group। ওই দ্বিতীয় group-টিরই fileটির উপর প্রভাব আছে। আপনি বিশটি group-এর সদস্য হলেও লাভ হবে কেবল তখনই, যখন file-এ সেগুলোর কোনো একটি group সেট করা থাকবে।
id
stat -c '%U %G %A %n' ~/permdemo/inner/notes.txtid আপনার user এবং আপনি যে সব group-এর সদস্য, সেগুলো দেখায়। stat file-এর owner এবং group দেখায়। দুটি তুলনা করলেই বোঝা যাবে kernel আপনার জন্য কোন triad ব্যবহার করবে।
এই কারণেই shared directory-তে সাধারণত একটি group এবং setgid bit সেট করা হয়। sudo chmod 2775 /srv/shared, drwxrwsr-x হিসেবে দেখায়। এর ভেতরে তৈরি file-গুলো creator-এর ব্যক্তিগত group-এর বদলে directory-এর group উত্তরাধিকারসূত্রে পায়। নতুন subdirectory-গুলোও setgid bit পায়। Setgid group নির্ধারণ করে, mode নয়। default umask 022 হলে ভেতরে তৈরি নতুন file-এর mode তবুও 644 হয়। ফলে teammates file পড়তে পারে, কিন্তু write করতে পারে না। Group write-এর জন্য সেখানে কাজ করা প্রত্যেকের umask 002 হতে হবে, অথবা directory-তে একটি default ACL থাকতে হবে। default ACL ওই directory-র ভেতরে তৈরি file-এর ক্ষেত্রে umask-এর পরিবর্তে প্রযোজ্য হয়। প্রতিটি service-এর জন্য আলাদা account ব্যবহার করা এই বিষয়টির অন্য দিক। এটি VPS-এ প্রতি service-এর জন্য একটি Linux user অংশে ব্যাখ্যা করা হয়েছে।
umask প্রতিটি নতুন ফাইলের mode নির্ধারণ করে
নতুন ফাইল তার mode আপনার কাছ থেকে পায় না। যে program ফাইলটি তৈরি করে, সেটির নির্ধারিত mode থেকে আপনার umask যে bit-গুলো সরিয়ে দেয়, নতুন ফাইলের mode তা থেকেই তৈরি হয়। umask সরিয়ে দেওয়ার bit-গুলোর একটি mask। তাই বড় umask হলে ফাইলের access আরও সীমিত হয়।
বেশিরভাগ distribution-এ ডিফল্ট হিসেবে 022 থাকে। একটি program সাধারণত regular file তৈরি করার সময় 0666 চায়। Directory তৈরি করার সময় সাধারণত 0777 চায়। umask উভয় request থেকেই 022 সরিয়ে দেয়। ফলে file-এর mode হয় 644 এবং directory-এর mode হয় 755। নতুন তৈরি VPS-এ সর্বত্র সাধারণত এই জোড়াই দেখা যায়।
umask
umask -S
touch ~/permdemo/new.txt && mkdir -p ~/permdemo/newdir
ls -ld ~/permdemo/new.txt ~/permdemo/newdirumask -S অক্ষর হিসেবে একই value দেখায়, যা 0022-এর চেয়ে পড়তে সহজ। আরও কঠোর default-এর জন্য ~/.profile-এ umask 027 সেট করুন। এতে file-এর mode হবে 640 এবং directory-এর mode হবে 750। ফলে আপনার group আপনার কাজ পড়তে পারবে, কিন্তু অন্য কেউ পারবে না। এই ফলাফল সাধারণ 0666 এবং 0777 request ধরে নেওয়া হয়েছে।
দুটি সীমাবদ্ধতা গুরুত্বপূর্ণ। umask কেবল bit সরাতে পারে, যোগ করতে পারে না। 0666 mode চেয়ে তৈরি করা কোনো file কখনো executable হবে না, আপনি যে value-ই সেট করুন না কেন; touch-ও 0666 চায়। কোনো program যদি শুধু owner-এর access চায়, সেটি বজায় থাকে: 022 বা 027—উভয় umask-এর ক্ষেত্রেই mktemp file তৈরি করে 600 mode-এ এবং directory তৈরি করে 700 mode-এ। আর কোনো systemd service আপনার shell profile পড়ে না। তাই value-টি unit file-এ সেট করুন।
[Service]
UMask=0027একটি ক্ষেত্রে umask সম্পূর্ণভাবে প্রযোজ্য হয় না। Parent directory-তে default ACL থাকলে umask উপেক্ষা করা হয় এবং নতুন file-এর permission bit inherited ACL থেকে আসে।
ওয়েব ফাইলের permission 644 এবং ওয়েব ডিরেক্টরির permission 755 কেন
একটি web server নিজস্ব account-এর অধীনে চলে: Debian এবং Ubuntu-তে www-data, Rocky এবং Alma-তে nginx। এই process-এর পরিবেশন করা ফাইলগুলোতে read permission এবং সেগুলোর উপরের ডিরেক্টরিগুলোতে traverse permission প্রয়োজন। ফাইলগুলোতে write permission দেওয়ার কোনো কারণ নেই। একটি static site-এ এটি কখনোই অনুমোদন করা উচিত নয়।
কোনো ফাইলে 644 দিলে owner-এর জন্য write এবং সবার জন্য read permission থাকে। ফলে deploy user ফাইল publish করতে পারে এবং web user সেগুলো পরিবেশন করতে পারে। কোনো ডিরেক্টরিতে 755 দিলে owner-এর জন্য write এবং সবার জন্য traverse permission থাকে। ফলে web user path ধরে এগোতে পারে, কিন্তু কোনো কিছু যোগ বা মুছতে পারে না। তাই application-এর কোনো bug থাকলেও সেটি পরিবেশন করা page-গুলো নতুন করে লিখতে পারে না।
Traverse rule-টি ঠিক এই জায়গাতেই সমস্যা তৈরি করে। Site যদি /home/deploy/site-এ থাকে, /home/deploy-এর permission 750 হয় এবং web user ডিরেক্টরিটির group-এ না থাকে, তাহলে web user home directory-তে ঢুকতেই পারে না। Request শেষ হয় HTTP 403 দিয়ে, এবং /var/log/nginx/error.log-এ এ ধরনের একটি line দেখা যায়:
open() "/home/deploy/site/index.html" failed (13: Permission denied), client: 203.0.113.5ওই 13 হলো EACCES, অর্থাৎ kernel permission প্রত্যাখ্যান করেছে। Network-এ কোনো সমস্যা নেই: port listening অবস্থায় আছে এবং request এসে পৌঁছেছে। Linux-এ listening port কীভাবে কাজ করে শিখতে থাকলে এই কারণেই বিষয়টি বিভ্রান্তিকর মনে হয়। namei -l /home/deploy/site/index.html চালিয়ে chain ধরে নিচের দিকে পড়ুন এবং অন্যদের জন্য x না থাকা প্রথম ডিরেক্টরিটি খুঁজুন।
Application যে ডিরেক্টরিতে write করে, যেমন upload path, সেটি ব্যতিক্রম। Wider mode ব্যবহার না করে ownership দিয়ে permission দিন: sudo chown -R www-data:www-data /srv/site/uploads, এবং mode 755 রাখুন। শুধু যে ডিরেক্টরিটির write permission প্রয়োজন, সেটিতেই write access রাখুন।
chmod, পুরো directory tree-তে একই permission না বসিয়ে
chmod দুই ধরনের syntax গ্রহণ করে। Octal পদ্ধতিতে একসঙ্গে সব নয়টি bit সেট করা হয়: chmod 644 notes.txt। Symbolic পদ্ধতিতে শুধু উল্লেখ করা permission পরিবর্তিত হয় এবং বাকি permission অপরিবর্তিত থাকে: chmod u+x deploy.sh owner-এর জন্য execute যোগ করে, আর chmod go-w notes.txt group ও other-এর write permission সরিয়ে দেয়।
Recursion ব্যবহার করলেই directory tree ক্ষতিগ্রস্ত হতে পারে। chmod -R 755 . প্রতিটি image এবং প্রতিটি config file-কে executable করে দেয়, কারণ chmod script এবং JPEG-এর মধ্যে পার্থক্য বুঝতে পারে না। এর পরিবর্তে বড় হাতের X ব্যবহার করুন।
chmod -R u=rwX,go=rX ~/permdemo
stat -c '%a %n' ~/permdemo ~/permdemo/inner/notes.txtবড় হাতের X directory-তে execute permission প্রয়োগ করে এবং যেসব file-এ আগে কোথাও execute bit ছিল, সেগুলিতেও তা বজায় রাখে। Directory-এর permission 755 হয়, সাধারণ file-এর permission 644 হয়, এবং আগে থেকেই executable থাকা script সেই permission ধরে রাখে। কোনো একটি file-এর mode নির্ভরযোগ্য হলে chmod --reference=good.sh other.sh সেটি অন্য file-এ কপি করে।
ভুল bit থাকলে যে বার্তাগুলো দেখা যায়
bash: ./deploy.sh: Permission denied বোঝায়, আপনার ক্ষেত্রে প্রযোজ্য triad-এ script-এর কোনো x bit নেই, অথবা তার path-এর কোনো directory-তে x নেই। প্রথম ক্ষেত্রে chmod u+x deploy.sh সমাধান করে।
bash: ./deploy.sh: cannot execute: required file not found ভিন্ন একটি ত্রুটি, তবে এর নাম বিভ্রান্তিকর। x bit ঠিক আছে, কিন্তু প্রথম লাইনে নির্দিষ্ট interpreter অনুপস্থিত। সাধারণত Windows line ending-এর কারণে এটি হয়। ফলে kernel /bin/bash\r নামে একটি interpreter খোঁজে। sed -i 's/\r$//' deploy.sh দিয়ে এটি ঠিক করুন।
Permissions 0644 for '/home/deploy/.ssh/id_ed25519' are too open. SSH client থেকে আসে। অন্য account-গুলো পড়তে পারে এমন private key ব্যবহার করতে SSH client অস্বীকার করে। key-এর permission 600 হওয়া উচিত এবং ~/.ssh-এর permission 700 হওয়া উচিত। সম্পূর্ণ key handling SSH key এবং এর file permission পরিচালনা-এ দেওয়া আছে।
Authentication refused: bad ownership or modes for directory /home/deploy/.ssh server-এর journal-এ দেখা যায়, যখন কোনো home directory বা তার .ssh group writable থাকে। sshd-এর StrictModes setting ওই key প্রত্যাখ্যান করে। client-এর দিক থেকে এটি কোনো ব্যাখ্যা ছাড়াই অপ্রত্যাশিত password prompt হিসেবে দেখা যায়।
sudo: /etc/sudoers is world writable-এর পরে sudo: no valid sudoers sources found, quitting দেখা গেলে বোঝায়, sudo তার নিজস্ব config-এর mode পরীক্ষা করে চালু হতে অস্বীকার করেছে। ওই file-এর mode 0440 হওয়া উচিত এবং এটি কখনোই world writable হওয়া উচিত নয়। সাধারণত বিস্তৃত recursive chmod-এর পরে এই সমস্যা দেখা দেয়। উপরের sshd বার্তার সঙ্গেও এটি একসঙ্গে ঘটতে পারে। সে ক্ষেত্রে provider-এর console-ই আবার প্রবেশের একমাত্র উপায় হয়ে থাকে।
কেন 777 কোনো সমাধান নয়
777 মেশিনের প্রতিটি account এবং ওই account-গুলোর অধীনে চলা প্রতিটি process-কে write access দেয়। সার্ভারে service-গুলো সাধারণত নিজস্ব user-এর অধীনে চলে। তাই VPS-এ “everyone” বলতে laptop-এর তুলনায় অনেক বেশি account ও process বোঝায়। কোনো service compromise হলে 777 অনুমতি থাকা যেকোনো জায়গায় লিখতে পারে।
web root-এর ক্ষেত্রে ক্ষতি সরাসরি হয়। server যে directory serve করে সেটি world-writable হলে file upload-এর ত্রুটি ব্যবহার করে সেখানে script বসানো এবং পরে সেটি request করা সম্ভব হয়।
Ownership-সংক্রান্ত সমস্যার সমাধান হিসেবে 777 প্রায় সবসময়ই ভুল। লক্ষণ হলো, “app এই directory-তে লিখতে পারছে না।” কারণ হলো directory-টির মালিকানা ভুল user-এর কাছে রয়েছে। sudo chown -R appuser:appuser /srv/app/storage এবং mode 755 ব্যবহার করলে সমস্যাটি সমাধান হয়: application সেখানে লিখতে পারে, আর অন্য account-গুলো directory-টির তালিকা দেখতে ও প্রবেশ করতে পারে, কিন্তু সেখানে লিখতে পারে না। কোনো কিছু deploy করার আগে এসব account তৈরি করার বিষয়টি নতুন VPS-এর প্রথম দশ মিনিটের কাজের অন্তর্ভুক্ত।
World write একটি পরিচিত নির্দিষ্ট জায়গায় বৈধ: /tmp। এর সঠিক বানান হলো drwxrwxrwt। শেষের t হলো sticky bit: directory-টি সবার জন্য writable থাকে, কিন্তু কোনো user শুধু নিজের মালিকানাধীন file মুছতে পারে। এই bit না থাকলে যেকোনো account অন্য account-এর temporary file মুছে ফেলতে পারত।
পরিবর্তনের আগে mode দেখুন
এই কমান্ডগুলো শুধু বর্তমান অবস্থা পড়ে। তাই যেকোনো জায়গা থেকে নিরাপদে চালানো যায়।
id
umask
stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt
namei -l ~/permdemo/inner/notes.txt
find ~/permdemo -perm -0002find <path> -perm -0002 এমন একটি path-এর অধীনে থাকা সবকিছু তালিকাভুক্ত করে, যার world write bit সেট করা আছে। কেউ chmod 777 ব্যবহার করে মেরামতের কাজ করার পর কোনো server audit করার এটি সবচেয়ে দ্রুত উপায়।
কোনো নির্দিষ্ট service account একটি directory-তে প্রবেশ করতে পারে কি না জানতে, সেই account হিসেবে পরীক্ষা করুন। ওই user-এর directory-তে traverse permission থাকলে sudo -u www-data test -x /srv/site && echo yes || echo no, yes প্রিন্ট করে। না থাকলে no প্রিন্ট করে। root হিসেবে পরীক্ষা করলে কোনো তথ্য পাওয়া যায় না, কারণ root এই check এড়িয়ে যায় এবং ফলাফল সবসময় yes হয়।
FAQ
Linux-এ drwxr-xr-x-এর অর্থ কী?
এটি একটি directory, যা শুরুর d দ্বারা চিহ্নিত, এবং এর mode 755। owner triad হলো rwx, তাই owner-এর এতে সব permission আছে। group triad হলো r-x এবং other triad হলো r-x। তাই অন্য সবাই ভেতরের নামগুলো list করতে এবং directory-এর মধ্য দিয়ে যেতে পারে, কিন্তু owner ছাড়া কেউ কিছু যোগ বা মুছতে পারে না। যেকোনো path-এর জন্য stat -c '%A %a %U %G %n' <path> চালান। এটি letter form এবং octal form পাশাপাশি দেখায়।
Web file-এর mode 644 এবং web directory-এর mode 755 কেন?
Web server একটি আলাদা account-এর অধীনে চলে। Ubuntu-তে account-টি হলো www-data। এটি যে file serve করে সেগুলোতে read permission এবং সেগুলোর উপরের প্রতিটি directory-তে traverse permission প্রয়োজন। কোনো ক্ষেত্রেই তার write permission প্রয়োজন হয় না। 644 owner-কে write এবং অন্য সবাইকে read permission দেয়। 755 owner-কে write এবং অন্য সবাইকে traverse permission দেয়। যে directory-তে application-এর সত্যিই write করা দরকার, সেটি chown দিয়ে ওই application-এর user-এর অধীনে দিন। সবার জন্য mode বাড়াবেন না।
x bit-এর অর্থ কি আমি directory execute করতে পারি?
না। Directory-তে x-এর অর্থ traverse। Kernel যখন path অতিক্রম করে, তখন এর মাধ্যমে directory-এর ভেতরের একটি নাম resolve করা যায়। cd-এর এটি প্রয়োজন। Directory-এর নিচের কোনো file open করতেও এটি প্রয়োজন। Path-এর প্রতিটি directory-তে x থাকতে হয়। তাই mode 644-এর কোনো file-এ পৌঁছানো যায় না, যদি তার উপরের কোনো directory-তে আপনার জন্য x না থাকে। Path-এর প্রতিটি directory-এর mode দেখাতে namei -l /path/to/file চালান। এতে lookup কোথায় থামছে তা দেখা যায়।
chmod 777 কি কখনো সঠিক সমাধান?
Server-এ প্রায় কখনোই নয়। এটি মেশিনের প্রতিটি account-কে write permission দেয়, service যে account-এর অধীনে চলে সেটিও এর অন্তর্ভুক্ত। ফলে কোনো compromised service file-টি পরিবর্তন করতে পারে। কোনো application directory-তে write করতে না পারলে আসল সমস্যা সাধারণত ownership। sudo chown -R appuser:appuser /srv/app/storage-কে mode 755 দিয়ে দিলে application write access পায়। অন্য account-গুলো directory read করতে পারে, কিন্তু এতে write করতে পারে না। পরিচিত ব্যতিক্রম হলো /tmp, যার mode 1777। এটি কাজ করে কারণ sticky bit ব্যবহারকারীদের একে অপরের file মুছে ফেলা বন্ধ করে।
ls permission-এর পরে dot বা plus দেখায় কেন?
এই একাদশ character নয়টি permission bit-এর বাইরের নিয়ম নির্দেশ করে। drwxr-xr-x.-এর মতো dot থাকলে বোঝায় যে একটি SELinux security context সংযুক্ত আছে। Fedora এবং Rocky-তে এটি স্বাভাবিক। drwxr-xr-x+-এর মতো plus থাকলে বোঝায় যে একটি POSIX ACL (access control list) সেট করা আছে। অর্থাৎ কোনো user বা group-এর এমন permission আছে, যা তিনটি triad-এ দেখা যায় না। অতিরিক্ত entry-গুলো list করতে getfacl <path> চালান।