drwxr-xr-x کا مطلب اور Linux permissions

drwxr-xr-x کا مطلب

drwxr-xr-x ایسی directory کو بیان کرتا ہے جس میں اس کا مالک تبدیلی کر سکتا ہے، جبکہ ہر دوسرا user بغیر کسی تبدیلی کے اسے پڑھ اور اس میں داخل ہو سکتا ہے۔ octal میں یہ mode 755 ہوتا ہے۔ Linux ہر لائن کے شروع میں ls -l output کے یہ دس characters دکھاتا ہے، اور ایک ہی ترتیب میں ہمیشہ ان کا مطلب یکساں رہتا ہے۔ اس لیے ایک string سیکھنے سے آپ یہ سب سمجھ سکتے ہیں۔

باقی قواعد سے پہلے ایک اہم قاعدہ ہے، کیونکہ اسی سے طے ہوتا ہے کہ آپ کی testing سے کوئی نتیجہ نکلے گا یا نہیں۔ root user permission bits کو نظرانداز کرتا ہے۔ kernel root کو CAP_DAC_OVERRIDE capability (discretionary access control override) دیتا ہے، اس لیے root ایسی files بھی کھول سکتا ہے جن کا mode اس کی اجازت نہیں دیتا۔ اس page کی ہر مثال root کے لیے کامیاب ہو گی، bits کچھ بھی بتا رہی ہوں۔ جب آپ قواعد کا عملی اثر دیکھنا چاہیں تو normal user کے طور پر log in کریں۔

دس کریکٹرز، ایک وقت میں ایک

دیکھنے کے لیے ایک ڈائریکٹری اور ایک فائل بنائیں۔ یہاں کوئی بھی عمل نئی ڈائریکٹری سے باہر موجود کسی چیز کو متاثر نہیں کرتا۔

mkdir -p ~/permdemo/inner
printf 'hello\n' > ~/permdemo/inner/notes.txt
ls -ld ~/permdemo ~/permdemo/inner ~/permdemo/inner/notes.txt

عام default umask یعنی 022 کے ساتھ، ڈائریکٹری کی دونوں لائنیں drwxr-xr-x سے شروع ہوتی ہیں، جبکہ فائل کی لائن -rw-r--r-- سے شروع ہوتی ہے۔

کریکٹر 1 فائل کی قسم ظاہر کرتا ہے، یہ permission نہیں ہے۔ d ڈائریکٹری ہے۔ - عام فائل ہے۔ l symbolic link ہے۔ c اور b character اور block device nodes ہیں۔ s socket ہے، جبکہ p named pipe ہے۔ یہ octal value سے باہر ہوتا ہے، اسی لیے drwxr-xr-x کی قدر 755 بنتی ہے، نہ کہ d سے شروع ہونے والی کوئی قدر۔

اس کے بعد کے 9 کریکٹرز تین، تین کے گروپس میں ہوتے ہیں، اور ان کی ترتیب کبھی تبدیل نہیں ہوتی۔

• کریکٹرز 2 سے 4 owner triad ہیں۔ یہ ان bits کو ظاہر کرتے ہیں جو فائل کے مالک user پر لاگو ہوتی ہیں۔
• کریکٹرز 5 سے 7 group triad ہیں۔ یہ ان bits کو ظاہر کرتے ہیں جو فائل کے group پر لاگو ہوتی ہیں۔
• کریکٹرز 8 سے 10 other triad ہیں۔ یہ ان bits کو ظاہر کرتے ہیں جو باقی تمام users پر لاگو ہوتی ہیں۔

Triad کے اندر slots کی ترتیب ہمیشہ r، پھر w، پھر x ہوتی ہے، اور dash کا مطلب ہے کہ متعلقہ bit بند ہے۔ حروف اپنی جگہ تبدیل نہیں کرتے۔ r-x کا مطلب read کے بغیر write ہے۔ -w- کا مطلب write کے بغیر read ہے۔ یہ قانونی مگر نایاب permission ہے۔

لہٰذا drwxr-xr-x اس طرح تقسیم ہوتا ہے: d ڈائریکٹری کے لیے، پھر rwx owner کے لیے، پھر r-x group کے لیے، اور پھر r-x other کے لیے۔

کچھ systems گیارہواں کریکٹر بھی دکھاتے ہیں۔ آخر میں موجود dot، drwxr-xr-x.، کا مطلب ہے کہ فائل کے ساتھ SELinux (security enhanced Linux) context موجود ہے۔ Fedora اور Rocky جیسی SELinux distributions اسے default طور پر دکھاتی ہیں۔ آخر میں موجود plus، drwxr-xr-x+، کا مطلب ہے کہ فائل کے ساتھ POSIX ACL (access control list) موجود ہے۔ یہ ان 9 bits کے علاوہ rules کا ایک اضافی مجموعہ ہوتا ہے۔ ان اضافی rules کو getfacl <path> سے پڑھیں۔

ڈائریکٹری میں r، w اور x مختلف کام کرتے ہیں

یہ پہلا اصول ہے جس میں beginners اکثر غلطی کرتے ہیں۔ فائل اور ڈائریکٹری پر حروف ایک جیسے ہوتے ہیں، لیکن ان سے ملنے والے اختیارات مختلف ہوتے ہیں۔

• فائل پر r اس کا content پڑھتا ہے۔ ڈائریکٹری پر r اندر موجود ناموں کی فہرست دکھاتا ہے، اور plain ls کو یہی درکار ہوتا ہے۔
• فائل پر w اس کے content میں تبدیلی کرتا ہے۔ ڈائریکٹری پر w اس میں entries شامل اور حذف کرتا ہے۔ فائل حذف کرنا ڈائریکٹری میں تبدیلی ہے، اس لیے فیصلہ ڈائریکٹری پر موجود write permission کرتی ہے؛ فائل کے اپنے mode کا اس پر کوئی اثر نہیں ہوتا۔
• فائل پر x اسے program کے طور پر چلاتا ہے۔ ڈائریکٹری پر x اس کے اندر traversal کی اجازت دیتا ہے، یعنی kernel path lookup کے دوران اس کے اندر موجود کسی نام کو resolve کر سکتا ہے۔

Traversal وہ حصہ ہے جو لوگوں کو حیران کرتا ہے۔ ڈائریکٹری پر x کسی چیز کو execute نہیں کرتا۔ /srv/site/index.html کھولنے کے لیے پہلے x پر /، پھر x پر /srv، پھر x پر /srv/site، اور آخر میں فائل پر r درکار ہوتا ہے۔ اگر اس سلسلے میں کسی ڈائریکٹری پر آپ کے لیے x موجود نہ ہو تو lookup وہیں رک جاتا ہے، اور caller کو پورے path کے لیے Permission denied بتایا جاتا ہے، چاہے آخر میں موجود فائل world-readable ہو۔ namei -l /srv/site/index.html chain کے ہر مرحلے کو اس کے mode اور owner کے ساتھ دکھاتا ہے، تاکہ آپ دیکھ سکیں کہ رکاوٹ کہاں پیدا ہو رہی ہے۔

r والی اور x کے بغیر ڈائریکٹری ایک عجیب half state ہوتی ہے، جسے پہچاننا ضروری ہے۔ عام user ناموں کی فہرست دیکھ سکتا ہے، کیونکہ listing کی اجازت r دیتا ہے، لیکن کسی entry پر stat نہیں چلا سکتا۔ اس لیے ls -l size اور mode کے columns میں question marks دکھاتا ہے اور ہر entry کے لیے ls: cannot access ...: Permission denied پرنٹ کرتا ہے۔

حروف کو 755 میں تبدیل کرنا

ہر triad تین بٹ کا عدد ہوتا ہے۔ r کی قدر 4، w کی قدر 2، اور x کی قدر 1 ہے۔ فعال bits کی قدریں جمع کریں۔

• rwx = 4 + 2 + 1 = 7
• rw- = 4 + 2 = 6
• r-x = 4 + 1 = 5
• r-- = 4
• --- = 0

اس لیے drwxr-xr-x owner کے لیے 7، group کے لیے 5، اور other کے لیے 5 ہے: 755۔ -rw-r--r-- کی قدریں 6، 4، 4 ہیں: 644۔ drwxrwxr-x کی قدریں 7، 7، 5 ہیں: 775، یعنی group کے لیے write شامل کرنے پر 755۔ آپ کو characters ہاتھ سے گننے کی ضرورت نہیں، کیونکہ stat دونوں forms ایک ساتھ دکھاتا ہے۔

stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt

%A letter form ہے، %a octal form ہے، جبکہ %U اور %G owning user اور owning group کے نام بتاتے ہیں۔

وہ permission strings جنہیں لوگ تلاش کرتے ہیں

یہ وہ modes ہیں جو حقیقی server پر عام طور پر نظر آتے ہیں۔ ساتھ octal value اور ہر mode کے عام استعمال کی مثال بھی دی گئی ہے۔

• -rw-r--r--، 644 ہے۔ ایسی ordinary files جنہیں service صرف read کرتی ہے، مثلاً config file یا HTML page۔
• -rw-------، 600 ہے۔ Secrets: SSH private key یا کسی application کی .env file۔
• -rw-rw-r--، 664 ہے۔ ایسے directory میں موجود file جسے group کے ارکان share کرتے ہوں اور teammates کو اس میں write کرنے کی ضرورت ہو۔
• -rwxr-xr-x، 755 ہے۔ Scripts اور binaries، مثلاً /usr/local/bin/backup.sh اور زیادہ تر /usr/bin۔
• -rwx------، 700 ہے۔ ایسا private script جسے صرف اس کا owner run کر سکتا ہے۔
• drwxr-xr-x، 755 ہے۔ تقریباً ہر system directory اور website کا document root۔
• drwx------، 700 ہے۔ ~/.ssh اور locked-down box پر home directories۔
• drwxrwxr-x، 775 ہے۔ ایسا directory جس میں owner کا group write کر سکتا ہو۔
• drwxrwsr-x، 2775 ہے۔ یہی permission setgid bit کے ساتھ، تاکہ اس directory کے اندر بننے والی نئی files کو directory کا group وراثت میں ملے۔
• drwxrwxrwt، 1777 ہے۔ /tmp۔ آخری t sticky bit ہے، اس لیے user صرف اپنی files delete کر سکتا ہے۔
• -rwsr-xr-x، 4755 ہے۔ ایسا setuid binary جو اپنے owner کے طور پر run ہوتا ہے، مثلاً /usr/bin/passwd اور /usr/bin/sudo۔
• -rw-rw-rw-، 666 ہے، اور drwxrwxrwx، 777 ہے۔ World-writable permission server پر تقریباً ہمیشہ غلطی ہوتی ہے۔
• lrwxrwxrwx وہ value ہے جو ہر symbolic link دکھاتا ہے۔ Linux link کے mode bits کو نظرانداز کرتا ہے اور target کو check کرتا ہے، اس لیے اس string کا کوئی مفہوم نہیں ہوتا۔

آپ پر کون سا triad لاگو ہوتا ہے

یہ دوسری بات ہے جس میں beginners اکثر غلطی کرتے ہیں۔ kernel بالکل ایک triad منتخب کرتا ہے اور وہیں رک جاتا ہے۔

اگر آپ کی user ID file کے owner سے match کرتی ہے تو آپ کو owner triad ملتا ہے، اور group اور other bits کبھی consult نہیں کیے جاتے۔ بصورت دیگر، اگر file کا group آپ کے groups میں شامل ہے تو آپ کو group triad ملتا ہے۔ ورنہ آپ کو other triad ملتا ہے۔

اس کے دو نتائج نکلتے ہیں۔ owner triad اس وقت بھی لاگو ہوتا ہے جب وہ سب سے زیادہ restrictive ہو۔ mode 0466 والی file، جو -r--rw-rw- کے طور پر دکھائی جاتی ہے، اپنے owner کو صرف read کی اجازت دیتی ہے، جبکہ باقی سب write کر سکتے ہیں، کیونکہ owner check پہلے match ہو گیا اور اس کے بعد کچھ نہیں پڑھا گیا۔ یہ قانونی رویہ ہے، اور پہلی بار سامنا ہونے پر سب کو الجھن ہوتی ہے۔

اس کے بعد group triad کا انتخاب file کے group سے ہوتا ہے، نہ کہ ان groups کی فہرست سے جن میں آپ شامل ہیں۔ ls -l ہر line پر دو names دکھاتا ہے: پہلے owner، پھر group۔ صرف دوسرے group کو اس file کے بارے میں کوئی اختیار حاصل ہے۔ بیس groups میں شامل ہونا صرف اسی وقت فائدہ دیتا ہے جب file ان میں سے کسی ایک group سے وابستہ ہو۔

id
stat -c '%U %G %A %n' ~/permdemo/inner/notes.txt

id آپ کا user اور ان تمام groups کو دکھاتا ہے جن میں آپ شامل ہیں۔ stat file کا owner اور group دکھاتا ہے۔ دونوں کا موازنہ کریں، اور آپ جان لیں گے کہ kernel آپ کے لیے کون سا triad استعمال کرے گا۔

اسی وجہ سے shared directory کو عموماً ایک group اور setgid bit دیا جاتا ہے۔ sudo chmod 2775 /srv/shared، drwxrwsr-x کے طور پر دکھائی دیتا ہے، اور اس کے اندر بننے والی files creator کے personal group کے بجائے directory کا group inherit کرتی ہیں، تاکہ اگلا شخص بھی ان میں write کر سکے۔ ہر service کو اپنا account دینا اس طریقۂ کار کا دوسرا حصہ ہے، اور اس کی وضاحت VPS پر ہر service کے لیے ایک Linux user میں کی گئی ہے۔

umask ہر نئی فائل کا mode طے کرتا ہے

نئی فائل اپنا mode آپ سے حاصل نہیں کرتی۔ یہ mode اسے بنانے والے program سے حاصل کرتی ہے، پھر آپ کا umask جن bits کو clear کرتا ہے وہ حذف ہو جاتے ہیں۔ umask حذف کیے جانے والے bits کا mask ہے، اس لیے بڑا umask زیادہ private فائلیں بناتا ہے۔

زیادہ تر distributions میں default value 022 ہوتی ہے۔ Regular file بنانے والا program 0666 کی درخواست کرتا ہے۔ Directory بنانے والا program 0777 کی درخواست کرتا ہے۔ umask دونوں درخواستوں سے 022 clear کرتا ہے، اس لیے فائلوں پر 644 اور directories پر 755 حاصل ہوتا ہے۔ تازہ VPS پر آپ کو یہی جوڑا ہر جگہ نظر آتا ہے۔

umask
umask -S
touch ~/permdemo/new.txt && mkdir -p ~/permdemo/newdir
ls -ld ~/permdemo/new.txt ~/permdemo/newdir

umask -S یہی value حروف کی صورت میں دکھاتا ہے، جو 0022 کے مقابلے میں پڑھنا آسان ہے۔ زیادہ سخت default کے لیے umask 027 کو ~/.profile میں set کریں: فائلوں پر 640 اور directories پر 750، تاکہ آپ کا group آپ کے کام کو پڑھ سکے اور کوئی دوسرا نہ پڑھ سکے۔

دو حدود اہم ہیں۔ umask صرف bits clear کر سکتا ہے، انہیں add نہیں کر سکتا۔ اسی لیے آپ کوئی بھی value set کریں، نئی بننے والی فائل کبھی executable نہیں ہوتی۔ دوسری طرف، systemd service آپ کا shell profile نہیں پڑھتی، اس لیے یہ value unit file میں set کریں۔

[Service]
UMask=0027

ویب فائلیں 644 اور ویب ڈائریکٹریاں 755 کیوں ہوتی ہیں

ایک ویب سرور اپنے الگ account کے تحت چلتا ہے: Debian اور Ubuntu پر www-data، جبکہ Rocky اور Alma پر nginx۔ اس process کو serve کی جانے والی فائلوں پر read permission اور ان تک پہنچنے والی اوپری ڈائریکٹریوں پر traverse permission درکار ہوتی ہے۔ اسے ان فائلوں میں write کرنے کی کوئی وجہ نہیں ہوتی، اور static site کو کبھی بھی اس کی اجازت نہیں دینی چاہیے۔

کسی فائل پر 644 owner کو write اور سبھی کو read permission دیتا ہے، اس لیے deploy user فائل publish کر سکتا ہے اور web user اسے serve کر سکتا ہے۔ کسی ڈائریکٹری پر 755 owner کو write اور سبھی کو traverse permission دیتا ہے، اس لیے web user path پر آگے بڑھ سکتا ہے، لیکن کچھ شامل یا حذف نہیں کر سکتا۔ اس صورت میں application کا کوئی bug ان pages کو rewrite نہیں کر سکتا جنہیں وہ serve کر رہی ہے۔

Traverse rule اسی مقام پر اثر انداز ہوتی ہے۔ اگر site /home/deploy/site میں موجود ہو اور /home/deploy کی mode 750 ہو، تو web user home directory میں داخل ہی نہیں ہو سکتا، اور request HTTP 403 پر ختم ہو جاتی ہے۔ /var/log/nginx/error.log میں اس جیسی ایک سطر نظر آئے گی:

open() "/home/deploy/site/index.html" failed (13: Permission denied), client: 203.0.113.5

یہ 13 EACCES ہے، یعنی kernel کی جانب سے permission refusal۔ Network میں کوئی خرابی نہیں: port listening پر ہے اور request پہنچ چکی ہے۔ اسی وجہ سے Linux پر listening ports کیسے کام کرتے ہیں سیکھتے وقت یہ مسئلہ الجھن پیدا کرتا ہے۔ namei -l /home/deploy/site/index.html چلائیں اور chain میں اوپر سے نیچے تک دیکھیں کہ دوسری user کے لیے x کے بغیر پہلی directory کون سی ہے۔

جس directory میں application write کرتی ہو، مثلاً upload path، وہ exception ہے۔ اس کے لیے وسیع mode دینے کے بجائے ownership استعمال کریں: sudo chown -R www-data:www-data /srv/site/uploads اور mode 755 برقرار رکھیں۔ Write access صرف اسی directory تک محدود رکھیں جسے اس کی ضرورت ہے۔

chmod، پوری directory tree کو یکساں کیے بغیر

chmod دونوں صورتوں میں استعمال ہوتا ہے۔ Octal syntax ایک ہی بار میں تمام نو bits مقرر کرتی ہے: chmod 644 notes.txt۔ Symbolic syntax صرف نامزد permission تبدیل کرتی ہے اور باقی کو برقرار رکھتی ہے: chmod u+x deploy.sh مالک کے لیے execute permission شامل کرتا ہے، جبکہ chmod go-w notes.txt group اور other سے write permission ہٹا دیتا ہے۔

Recursion کے دوران directory tree کو نقصان پہنچ سکتا ہے۔ chmod -R 755 . ہر image اور ہر configuration file کو executable بنا دیتا ہے، کیونکہ chmod script اور JPEG میں فرق نہیں کر سکتا۔ اس کے بجائے capital X استعمال کریں۔

chmod -R u=rwX,go=rX ~/permdemo
stat -c '%a %n' ~/permdemo ~/permdemo/inner/notes.txt

Capital X directories پر execute permission لاگو کرتا ہے، اور ان files پر بھی جن میں پہلے سے کہیں execute bit موجود ہو۔ نتیجتاً directories کی mode 755، عام files کی mode 644 ہو جاتی ہے، جبکہ پہلے سے executable scripts اسی حالت میں رہتی ہیں۔ جب کسی ایک file کی mode قابلِ اعتماد ہو تو chmod --reference=good.sh other.sh اسے دوسری files پر نقل کرتا ہے۔

غلط ہونے پر ظاہر ہونے والے پیغامات

bash: ./deploy.sh: Permission denied کا مطلب ہے کہ اسکرپٹ میں آپ پر لاگو ہونے والے triad میں x bit موجود نہیں، یا اس کے path میں کسی directory پر x موجود نہیں۔ chmod u+x deploy.sh پہلی صورت کو درست کرتا ہے۔

bash: ./deploy.sh: cannot execute: required file not found ایک مختلف خرابی ہے، لیکن اس کا نام الجھن پیدا کرتا ہے۔ x bit درست ہے، مگر پہلی سطر میں درج interpreter موجود نہیں۔ عام وجہ Windows line endings ہوتی ہیں، اس لیے kernel /bin/bash\r نامی interpreter تلاش کر رہا ہوتا ہے۔ اسے sed -i 's/\r$//' deploy.sh سے درست کریں۔

Permissions 0644 for '/home/deploy/.ssh/id_ed25519' are too open. SSH client کی طرف سے آتا ہے، جو ایسی private key استعمال کرنے سے انکار کرتا ہے جسے دوسرے accounts پڑھ سکتے ہوں۔ key کے لیے 600 اور ~/.ssh کے لیے 700 ہونا چاہیے۔ key handling کی مکمل وضاحت SSH keys اور ان کی file permissions کا انتظام میں ہے۔

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 ہونا چاہیے۔ یہ عام طور پر وسیع recursive chmod کے بعد پیدا ہونے والی خرابی ہے، اور sshd کا مذکورہ پیغام بھی اسی کے ساتھ آ سکتا ہے۔ ایسی صورت میں واپس رسائی حاصل کرنے کا واحد طریقہ provider کا console رہ جاتا ہے۔

777 حل کیوں نہیں ہے

777 مشین پر موجود ہر account اور ان accounts کے تحت چلنے والے ہر process کو write access دیتا ہے۔ سرور services کو ان کے اپنے users کے تحت چلاتا ہے، اس لیے VPS پر "everyone" کا دائرہ laptop کے مقابلے میں کہیں زیادہ وسیع ہوتا ہے۔ اگر کوئی service compromise ہو جائے تو وہ ہر اس جگہ لکھ سکتی ہے جہاں 777 اجازت دیتا ہے۔

web root کے اندر نقصان براہِ راست ہوتا ہے۔ ایسی directory جس پر ہر account کو write access حاصل ہو اور جسے server serve بھی کرتا ہو، file upload کی خامی کو script رکھنے اور پھر اسے request کرنے کا ذریعہ بنا دیتی ہے۔

Ownership کے مسئلے کے لیے 777 تقریباً ہمیشہ غلط حل ہے۔ علامت یہ ہوتی ہے کہ "app اس directory میں write نہیں کر سکتی"۔ اصل وجہ یہ ہوتی ہے کہ directory غلط user کی ملکیت ہے۔ sudo chown -R appuser:appuser /srv/app/storage کو mode 755 کے ساتھ استعمال کرنے سے مسئلہ حل ہو جاتا ہے اور باقی تمام accounts کو باہر رکھا جاتا ہے۔ کسی بھی چیز کو deploy کرنے سے پہلے یہ accounts بنانا نئے VPS کے ابتدائی دس منٹ میں شامل ہونا چاہیے۔

World write ایک معروف جگہ پر جائز ہے، یعنی /tmp، اور اس کا mode drwxrwxrwt لکھا جاتا ہے۔ آخر میں موجود t sticky bit ہے: directory پر ہر account write کر سکتا ہے، لیکن user صرف وہی files delete کر سکتا ہے جن کا مالک وہ خود ہو۔ اس bit کے بغیر کوئی بھی account دوسرے account کی temporary files delete کر سکتا ہے۔

تبدیل کرنے سے پہلے mode پڑھیں

یہ commands صرف موجودہ state پڑھتی ہیں، اس لیے انہیں کہیں بھی محفوظ طور پر چلایا جا سکتا ہے۔

id
umask
stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt
namei -l ~/permdemo/inner/notes.txt
find ~/permdemo -perm -0002

find <path> -perm -0002 ایسے path کے اندر موجود تمام چیزیں دکھاتا ہے جن کا world write bit set ہو۔ کسی کے chmod 777 کے ذریعے چیزیں درست کرنے کے بعد server کا audit کرنے کا یہ تیز ترین طریقہ ہے۔

یہ جاننے کے لیے کہ کوئی مخصوص service account کسی directory میں داخل ہو سکتا ہے یا نہیں، سوال اسی account کے طور پر کریں۔ sudo -u www-data test -x /srv/site && echo yes || echo no اس وقت yes دکھاتا ہے جب اس user کے پاس directory پر traverse permission ہو، اور اس وقت no دکھاتا ہے جب یہ permission نہ ہو۔ root کے طور پر سوال کرنے سے کچھ ثابت نہیں ہوتا، کیونکہ root یہ check bypass کر دیتا ہے اور جواب ہمیشہ yes ہوتا ہے۔

FAQ

Linux میں drwxr-xr-x کا کیا مطلب ہے؟

یہ ایک directory ہے، جسے ابتدائی d ظاہر کرتا ہے، اور اس کا mode 755 ہے۔ مالک کا triad rwx ہے، اس لیے مالک کو اس پر تمام permissions حاصل ہیں۔ group کا triad r-x اور others کا triad r-x ہے، اس لیے باقی سب لوگ اندر موجود ناموں کی فہرست دیکھ سکتے ہیں اور directory سے گزر سکتے ہیں، جبکہ مالک کے علاوہ کوئی بھی چیز شامل یا حذف نہیں کر سکتا۔ کسی بھی path کی تصدیق stat -c '%A %a %U %G %n' <path> سے کریں، جو letter form اور octal form ساتھ ساتھ دکھاتا ہے۔

web files 644 اور web directories 755 کیوں ہوتی ہیں؟

web server ایک مختلف account کے تحت چلتا ہے، جو Ubuntu پر www-data ہے۔ اسے اپنی فراہم کردہ files پر read permission اور ان کے اوپر موجود ہر directory پر traverse permission درکار ہوتی ہے، جبکہ اسے دونوں میں write کرنے کی ضرورت نہیں ہوتی۔ 644 مالک کو write اور باقی سب کو read دیتا ہے۔ 755 مالک کو write اور باقی سب کو traverse دیتا ہے۔ جس directory میں application کو واقعی write کرنا ہو، اسے mode سب کے لیے وسیع کرنے کے بجائے chown کے ذریعے اسی application کے user کے حوالے کریں۔

کیا x bit کا مطلب ہے کہ میں directory کو execute کر سکتا ہوں؟

نہیں۔ directory پر x سے مراد traverse ہے، یعنی kernel کے path پر چلتے وقت اس کے اندر موجود ایک نام کو resolve کرنے کا حق۔ cd کو بھی اس کی ضرورت ہوتی ہے، اور اس کے نیچے موجود کسی file کو open کرنے کے لیے بھی یہی درکار ہے۔ path میں شامل ہر directory کو x درکار ہوتا ہے، اس لیے mode 644 والی file بھی اس وقت ناقابل رسائی رہتی ہے جب اوپر موجود کسی directory میں آپ کے لیے x نہ ہو۔ namei -l /path/to/file chain میں موجود ہر directory کا mode دکھاتا ہے، جس سے معلوم ہو جاتا ہے کہ lookup کہاں رک رہا ہے۔

کیا chmod 777 کبھی درست حل ہوتا ہے؟

server پر تقریباً کبھی نہیں۔ یہ machine کے ہر account کو write permission دیتا ہے، ان accounts کو بھی جن کے تحت services چلتی ہیں، اس لیے ایک breached service file کو دوبارہ لکھ سکتی ہے۔ جب application کسی directory میں write نہیں کر سکتی تو اصل مسئلہ عموماً ownership ہوتا ہے: mode 755 کے ساتھ sudo chown -R appuser:appuser /srv/app/storage application کو مطلوبہ رسائی دیتا ہے اور باقی سب کو باہر رکھتا ہے۔ معروف استثنا /tmp ہے، جو 1777 پر ہوتا ہے، اور یہ صرف اس لیے محفوظ رہتا ہے کہ sticky bit users کو ایک دوسرے کی files حذف کرنے سے روکتا ہے۔

ls permissions کے بعد dot یا plus کیوں دکھاتا ہے؟

یہ گیارہواں character ان نو permission bits سے آگے موجود rules کو بیان کرتا ہے۔ drwxr-xr-x. میں موجود dot کا مطلب ہے کہ SELinux security context منسلک ہے، جو Fedora اور Rocky پر معمول کی بات ہے۔ drwxr-xr-x+ میں موجود plus کا مطلب ہے کہ POSIX ACL (access control list) مقرر ہے، اس لیے کسی user یا group کے پاس ایسی permissions ہیں جو تینوں triads میں ظاہر نہیں ہوتیں۔ ان اضافی entries کی فہرست دیکھنے کے لیے getfacl <path> چلائیں۔