مجوز فایل در لینوکس چیست؟ آموزش chmod و chown با مثال عملی

مجوز فایل در لینوکس چیست و چرا باید درست یادش بگیری؟

فرض کن توی یک تیم استاپ‌موشن کار می‌کنی. چند نفر ویدیو و صدا رو آماده می‌کنن و یک اسکریپت، فایل‌های خروجی رو برای تحویل بررسی می‌کنه. امروز اسکریپت رو اجرا می‌کنی و با Permission denied روبه‌رو می‌شی. اولین واکنش خیلی‌ها اینه که sudo بزنن یا مجوز فایل رو 777 کنن؛ ولی قبل از این کار باید بفهمیم چه چیزی جلوی اجرا رو گرفته. اینجاست که شناخت مجوز فایل در لینوکس واقعاً به درد می‌خوره.

برای فهم مجوز فایل در لینوکس، ببین خوندن یک فایل، تغییر دادنش، اجرا کردنش و حذف کردنش الزاماً به یک مجوز وابسته نیستن. ممکنه نتونی داخل فایل بنویسی، ولی بتونی از پوشه‌ای که توش قرار داره حذفش کنی. یا خود فایل مجوز خوندن داشته باشه، اما چون اجازه عبور از پوشه والد رو نداری، بهش نرسی. قراره این تفاوت‌ها رو فقط حفظ نکنیم؛ با چند آزمایش واقعی ببینیمشون.

توی این درس سراغ سطح دسترسی فایل در لینوکس می‌ریم؛ از rwx و معنی مجوزهای 644 و 755 تا آموزش chmod، مالکیت فایل و دستور chown. مهم‌تر از اعداد، یه روش عیب‌یابی یاد می‌گیری: مشخص کن چه کاربری، چه عملیاتی رو روی کدوم مسیر می‌خواد انجام بده. این روش بعدها توی مدیریت سرور، برنامه‌نویسی و امنیت لینوکس هم کمکت می‌کنه.

اگه هنوز با پوشه‌ها و ترمینال آشنا نیستی، قبل از شروع یه نگاه به درس لینوکس چیست، آموزش ترمینال لینوکس و ساختار فایل‌سیستم بنداز. برای مرور ساختن و بررسی فایل‌ها هم درس دستورات لینوکس به کارت میاد. اینجا هر دستور جدید رو درست قبل از استفاده توضیح می‌دم تا لازم نباشه بین چند مقاله عقب‌وجلو بری.

مجوز فایل در لینوکس چیست؟ آشنایی با user و group و others

جواب کوتاه اینه: مجوز فایل در لینوکس مشخص می‌کنه یک فرایند با هویت کاربر و گروه مشخص، در مدل معمول دسترسی، اجازه خوندن، نوشتن یا اجرای فایل رو داره یا نه. برای پوشه هم همین حروف رو داریم، ولی معنای عملی اون‌ها فرق می‌کنه. به این مدل Linux File Permissions می‌گن؛ البته همه ماجرا نیست، چون ACL، سیاست‌های امنیتی و محدودیت‌های فایل‌سیستم هم می‌تونن دخالت داشته باشن.

برای شروع سه دسته رو بشناس: user یا مالک فایل، group یا گروه مالک، و others یعنی بقیه. هرکدوم سه بیت مجوز دارن. مثلاً ممکنه خودت یک گزارش رو تغییر بدی، اعضای یک گروه فقط بخوننش و بقیه اصلاً نتونن بازش کنن. این سه ستون به معنای سه کاربر مشخص نیست؛ سیستم بر اساس هویت درخواست‌کننده، ستون مناسب رو انتخاب می‌کنه.

یه نکته ظریف در بررسی مجوز فایل در لینوکس: اگر مالک فایل باشی، معمولاً مجوزهای ستون مالک ملاک بررسی هستن. قرار نیست اگر ستون others آزادتر بود، سیستم اون رو به‌جای ستون مالک انتخاب کنه. نتیجه هم به هویت فرایند و گروه‌های مرتبطش وابسته‌ست، نه صرفاً کسی که پشت کیبورد نشسته. برای توضیح دقیق‌ترِ بررسی مسیرها، راهنمای فنی path_resolution در لینوکس رو می‌تونی ببینی.

اولین نگاه : دستور ls -l چه چیزی رو نشون می‌ده؟

قبل از اینکه سراغ تغییر مجوز فایل در لینوکس بری، وضعیت فعلی رو بخون. دستور ls -l نوع فایل، مجوزها، مالک، گروه، اندازه و چند مشخصه دیگه رو نشون می‌ده. اول یک نمونه نمایشی می‌بینیم؛ اسم‌های sara و editors واقعی نیستن و قرار نیست خروجی سیستم تو دقیقاً شبیه این باشه.

ls -l

-rw-r----- 1 sara editors 86 Oct 11 18:20 storyboard.txt
-rwxr-x--- 1 sara editors 52 Oct 11 18:21 preview.sh
drwxr-x--- 2 sara editors 4096 Oct 11 18:22 delivery

برای خوندن مجوز فایل در لینوکس، سطر -rwxr-x--- رو ببین. حرف اول - یعنی فایل معمولی و d یعنی پوشه. نه جای بعدی رو سه‌تا سه‌تا بخون: rwx برای مالک، r-x برای گروه و --- برای دیگران. یعنی مالک همه سه مجوز رو داره، گروه می‌تونه بخونه و اجرا کنه و دیگران در این مدل مجوزی ندارن. حالا به‌جای حفظ کردن کل رشته، فقط دنبال همین سه قسمت بگرد.

اگر کنار نمایش مجوزها علامت‌هایی مثل + یا . دیدی، ممکنه ACL یا اطلاعات امنیتی اضافه وجود داشته باشه. پس ده کاراکتر اولِ خروجی همیشه توضیح کامل یک خطای دسترسی نیستن. برای شروع همین ستون‌ها رو یاد بگیر؛ وقتی واقعاً به موردی برخوردیم که جواب ساده نداره، سراغ لایه‌های بعدی می‌ریم.

یه سؤال رو برای خودت عادت کن: «این عملیات با هویت کدوم کاربر انجام می‌شه؟» ممکنه تو به‌عنوان مالک به فایل دسترسی داشته باشی، اما سرویس وب با کاربر دیگه‌ای اجرا بشه و همون فایل رو نتونه بخونه. تا این تفاوت رو ندونی، دیدن مجوز 644 یا 755 به‌تنهایی برای حل مشکل کافی نیست.

سه حرف r و w و x چه معنی‌ای دارن؟

برای فایل معمولی : بخون، تغییر بده، اجرا کن

وقتی از مجوز فایل در لینوکس حرف می‌زنیم، برای فایل معمولی r یعنی اجازه خوندن محتوای فایل، w یعنی اجازه تغییر محتوای اون و x یعنی مجوز اجرای مستقیمش به‌عنوان برنامه یا اسکریپت. مثلاً برای خوندن گزارش با cat به حق خواندن نیاز داری. ولی x تضمین نمی‌کنه برنامه سالمه یا اجراش بدون خطا تموم می‌شه؛ فقط یکی از شرط‌های اجراست.

به هر فایلی نباید مجوز اجرا بدی. یک فایل عکس، PDF یا متن عادی معمولاً اصلاً قرار نیست اجرا بشه. وقتی کسی می‌گه «برای حل هر خطایی chmod 777 بزن»، داره مجوزهایی اضافه می‌کنه که شاید هیچ‌وقت لازم نبوده. توی بحث امنیت لینوکس، همین مجوزهای اضافی می‌تونن سطح خطر رو بالا ببرن.

یه تفاوت کاربردی هم هست: وقتی bash script.sh می‌زنی، خود Bash تلاش می‌کنه فایل رو بخونه و تفسیر کنه؛ پس در شرایط معمول ممکنه فایل بدون بیت x هم اجرا بشه. اما وقتی ./script.sh رو مستقیم صدا می‌زنی، علاوه بر مجوز عبور از مسیر، باید فایل قابل اجرا باشه و شیوه اجرای اون هم درست تعریف شده باشه. جلوتر هر دو حالت رو با هم مقایسه می‌کنیم.

برای پوشه : سه حرف آشنا، سه رفتار متفاوت

حالا برسیم به مجوز پوشه در لینوکس و فرقش با مجوز فایل در لینوکس. برای پوشه، r به دیدن نام ورودی‌ها مربوطه، w با داشتن اجازه عبور معمولاً امکان ساخت و حذف نام‌ها رو می‌ده، و x یعنی اجازه عبور از مسیر و دسترسی به نام مشخص داخل پوشه. پس x روی دایرکتوری به معنی «اجرا کردن پوشه» نیست. این فرق یکی از کلیدهای فهم خطاهای دسترسیه.

فرض کن نشانی notes/storyboard.txt رو بلدی و خود فایل هم خواندنیه. اگر روی پوشه notes اجازه عبور نداشته باشی، باز کردن فایل ممکن نیست. برعکس، ممکنه حق عبور داشته باشی و نام دقیق فایل رو بدونی، اما چون مجوز فهرست‌کردن پوشه رو نداری نتونی با ls محتویاتش رو ببینی. همین مثال نشون می‌ده چرا سطح دسترسی پوشه رو باید جدا از فایل بررسی کنی.

این فقط درباره پوشه نزدیک فایل نیست؛ همه دایرکتوری‌های بالادستی مسیر باید قابل عبور باشن. برای همین موقع عیب‌یابی Permission denied، اگر مجوز فایل درست به نظر می‌رسه، مسیر رو از اول بررسی کن. توی بخش عیب‌یابی با namei این کار رو ساده‌تر انجام می‌دیم.

یک معمای لینوکسی : چرا فایل فقط‌خواندنی رو می‌شه حذف کرد؟

برای فهم دقیق مجوز فایل در لینوکس، یه معما داریم: فایلی داری که مجوزش 400ه؛ یعنی مالک فقط اجازه خوندن داره. آیا ممکنه همون مالک فایل رو حذف کنه؟ بله، ممکنه! چون حذف نام فایل با تغییر محتوای فایل فرق داره. برای فهم درست مجوز فایل در لینوکس باید همیشه نوع عملیات رو هم در نظر بگیری.

وقتی فایلی رو حذف می‌کنی، در حالت معمول داری ورودی اون رو از دایرکتوری والد برمی‌داری. پس اجازه نوشتن و عبور از پوشه والد نقش اصلی رو دارن، نه بیت w روی خود فایل. یعنی حتی فایل فقط‌خواندنی هم ممکنه از پوشه‌ای که در اختیارته پاک بشه. پایین‌تر همین رفتار رو با فایل بی‌ارزش آزمایشی می‌بینی.

البته این رفتار استثنا هم داره. Sticky Bit روی پوشه‌های اشتراکی مثل /tmp، ویژگی Immutable، ACL یا محدودیت‌های فایل‌سیستم می‌تونن جلوی حذف رو بگیرن. پس از یک نمونه کوچک نتیجه نگیر همه فایل‌های لینوکس همیشه همین رفتار رو دارن. توی مقاله ما فقط مدل عادی رو تست می‌کنیم، نه همه سیاست‌های امنیتی ممکن رو.

مجوز عددی در لینوکس؛ از chmod 755 تا chmod 777

اگه درباره مجوز فایل در لینوکس جست‌وجو کرده باشی، احتمالاً موقع جست‌وجوی آموزش chmod با عددهایی مثل 644، 755 و 777 روبه‌رو شدی. منطقش ساده‌ست: r=4، w=2 و x=1. برای هر دسته مجوزها رو با هم جمع می‌کنی تا یک رقم از صفر تا هفت داشته باشی. سه رقم کنار هم، به‌ترتیب مجوز مالک، گروه و دیگران رو نشون می‌دن.

برای مثال مجوز 644 در لینوکس یعنی مالک می‌تونه فایل رو بخونه و تغییر بده، ولی گروه و دیگران فقط اجازه خوندن دارن. در مجوز 755 در لینوکس، مالک rwx و دو دسته دیگه r-x دارن. این نمایش سه‌رقمی همون حالت عددی یا Octal هست. فقط حواست باشه اعداد مشابه روی فایل و پوشه لزوماً کاربرد یکسانی ندارن.

هیچ عددی برای همه فایل‌ها و پوشه‌ها بهترین نیست. فایل خصوصی، اسکریپت اجرایی و پوشه عمومی نیاز یکسانی ندارن. اگر فقط صاحب فایل باید محتوای اون رو ببینه، شاید 600 منطقی باشه. اگر قراره دیگران بتونن از یک پوشه عبور کنن، ممکنه 755 مناسب باشه. مجوز درست از نیاز واقعی شروع می‌شه، نه از یک نسخه ثابت توی اینترنت.

در مقابل، مجوز 777 در لینوکس اجازه خواندن، نوشتن و اجرا رو برای هر سه دسته باز می‌کنه. عبارت chmod 777 رو زیاد می‌بینی، اما این دستور درمان عمومی Permission denied نیست. شاید یک مانع رو برداره، ولی هم‌زمان کاربران بیشتری اجازه دست‌کاری پیدا می‌کنن. محدودیت‌هایی مثل SELinux یا فایل‌سیستم فقط‌خواندنی هم ممکنه همچنان پابرجا باشن.

آموزش chmod در لینوکس؛ حالت نمادی بهتره یا عددی؟

حالا که می‌دونی chmod چیست، دو روش استفاده ازش رو یاد بگیریم. دستور chmod در لینوکس مجوزهای معمول فایل یا پوشه رو تغییر می‌ده. در حالت عددی کل مجوز رو مشخص می‌کنی؛ در حالت نمادی می‌گی فقط یک حق خاص اضافه یا کم بشه. مثلاً chmod u+x به مالک اجازه اجرا اضافه می‌کنه، بدون اینکه مجوز گروه و دیگران رو از اول بنویسی.

# نمونه‌های آموزشی: اول فایل مقصد واقعی و مالک اون رو بشناس.
# این نام‌ها فرضی هستن و بخش عملی پایین، تست قابل اجرا داره.
# chmod 640 report.txt
# chmod u+x preview.sh
# chmod g-w report.txt
# chmod o-rwx secret.txt

در حالت نمادی، u یعنی مالک، g گروه، o دیگران و a همه. علامت + مجوز اضافه می‌کنه، - کم می‌کنه و = اون دسته رو دقیقاً روی مجوز انتخابی می‌ذاره. برای نمونه chmod g=r file.txt یعنی گروه فقط اجازه خواندن داشته باشه. در این بخش نمونه‌ها آموزشی هستن؛ آزمایش قابل اجرا رو کمی جلوتر داخل پوشه مخصوص خودمون انجام می‌دیم.

گزینه -R هم برای تغییر بازگشتی وجود داره، ولی روی سرور واقعی باید خیلی مراقبش باشی. فرمان chmod -R 755 مجوز اجرای اضافه به فایل‌های عادی می‌ده و ممکنه سیاست امنیتی پروژه رو خراب کنه. اگر واقعاً لازم بود مجوزهای یک درخت رو اصلاح کنی، اول فایل‌ها و پوشه‌ها رو جدا بشناس؛ برای تنظیم انتخابی، شکل نمادی و X بزرگ هم کاربرد دارن. توضیحات رسمی رو در راهنمای GNU chmod بخون.

پروژه عملی : مجوزهای یک فایل استاپ‌موشن رو خودت مدیریت کن

بریم سراغ بخش عملی تا مجوز فایل در لینوکس رو روی یک پروژه واقعیِ آزمایشی لمس کنی. داستانمون درباره فایل‌های یک گروه استاپ‌موشنه: یک اسکریپت پیش‌نمایش داریم، یک یادداشت خصوصی و یک پوشه تحویل. همه فایل‌ها توی پوشه تصادفی داخل خانه کاربر ساخته می‌شن. قرار نیست روی فایل‌های سایت، پوشه‌های سیستم یا حساب‌های دیگه تغییری بدیم.

برای تست مجوز فایل در لینوکس، تمام دستورها رو در یک نشست Bash و با یک کاربر عادی اجرا کن، نه root. مسیر تمرین داخل متغیر LAB ذخیره می‌شه؛ اگر پنجره ترمینال رو ببندی، این متغیر در نشست بعدی خودبه‌خود برنمی‌گرده. اگر از WSL استفاده می‌کنی، تمرین رو داخل فایل‌سیستم خود توزیع، زیر $HOME اجرا کن، نه روی درایو ویندوز؛ چون رفتار مجوزهای فایل‌سیستم میزبان ممکنه متفاوت باشه.

مرحله اول : ساختن یک محیط آزمایشی بدون خطر

برای شروع با mktemp -d یک پوشه تازه و با نام غیرقابل‌پیش‌بینی می‌سازیم. umask 077 هم مجوزهای پیش‌فرض فایل‌های جدید رو محدودتر می‌کنه. این دستور تنظیم ماسک رو در همین نشست Shell تغییر می‌ده؛ اگر بعد از تمرین به مقدار قبلی نیاز داشتی باید اون رو برگردونی. فعلاً این بخش رو در ترمینال عادی اجرا کن تا رفتار مجوزها قابل مشاهده باشه.

ORIGINAL_UMASK="$(umask)"
umask 077
LAB="$(mktemp -d "$HOME/nb-stopmotion.XXXXXX")"
mkdir -p "$LAB/project/scripts" "$LAB/project/notes" "$LAB/project/delivery"
printf "%s\n" "لطفاً پیش‌نمایش قبل از انتشار بررسی شود." > "$LAB/project/notes/client-note.txt"
printf "#!/usr/bin/env bash\nprintf '%%s\n' 'render-ready'\n" > "$LAB/project/scripts/preview.sh"
printf "LAB=%s\n" "$LAB"
ls -ld "$LAB" "$LAB/project" "$LAB/project/scripts"

در خروجی مقدار LAB رو می‌بینی؛ چیزی شبیه /home/student/nb-stopmotion.A1B2C3. بخش آخر هر بار فرق داره و قرار نیست یک مسیر از قبل موجود رو پاک کنیم. اگر برنامه یا فایل‌های شخصی مهمی داری، باز هم قبل از اجرای هر دستور تغییردهنده، مسیرش رو ببین. قابل پیش‌بینی بودن محیط آزمایشی یعنی بتونی اثر هر فرمان رو محدود و بررسی کنی.

مرحله دوم : ببینیم مالک فایل کیه و مجوزها چیه

حالا باید بفهمیم فایل‌ها مال چه کسی هستن و با چه مجوزی ساخته شدن. دستور id شناسه کاربر و گروه‌ها رو نشون می‌ده و stat -c روی GNU/Linux می‌تونه مجوز نمادی، عددی، نام مالک و مسیر فایل رو کنار هم چاپ کنه. این همون روشی‌ه که برای بررسی سطح دسترسی فایل در لینوکس قبل از تغییرش لازم داریم.

id
stat -c "%A | %a | %U:%G | %n" "$LAB/project/notes/client-note.txt" "$LAB/project/scripts/preview.sh"

تا این مرحله هیچ مالکیتی رو تغییر ندادیم؛ فایل‌ها معمولاً متعلق به همون کاربری هستن که اون‌ها رو ساخته. تغییر مالک فایل در لینوکس با chown بحث جداگانه‌ایه و برای واگذاری به حساب دیگه اغلب اختیار مدیریتی می‌خواد. برای یادگیری مقدماتی بهتره اول مجوز فایل‌های خودت رو بررسی کنی، نه اینکه مالکیت فایل‌های سیستم رو عوض کنی.

مرحله سوم : خطای Permission denied در لینوکس رو عمداً بسازیم

برای آزمایش مجوز فایل در لینوکس، فایل preview.sh رو بدون مجوز اجرا ساختیم. حالا اول با ls -l مجوزش رو ببین و بعد تلاش کن مستقیم اجراش کنی. انتظار داریم اجرای مستقیم با خطای Permission denied و وضعیت ۱۲۶ روبه‌رو بشه. این یک خطای عمدی و کنترل‌شده‌ست، نه خرابی آموزش. متن خطا ممکنه بسته به Shell کمی فرق داشته باشه.

ls -l "$LAB/project/scripts/preview.sh"
"$LAB/project/scripts/preview.sh"

خیلی‌ها اینجا اولین کاری که می‌کنن اضافه کردن sudo هست. ولی فایل مال خودته و فقط بیت اجرا نداره؛ پس ساده‌ترین اصلاح، دادن همون اجازه لازم به مالک با chmod u+xه. قرار نیست برای رفع خطای Permission denied در لینوکس، مجوز کل سیستم رو باز کنیم. بعد از اصلاح، دقیقاً همون اسکریپت رو دوباره اجرا می‌کنیم.

chmod u+x "$LAB/project/scripts/preview.sh"
"$LAB/project/scripts/preview.sh"
stat -c "%A | %a | %n" "$LAB/project/scripts/preview.sh"

اگر همه‌چیز طبق انتظار باشه، خروجی render-ready ظاهر می‌شه و stat مجوز 700 رو برای اسکریپت نشون می‌ده. این آزمایش فقط ثابت می‌کنه مجوز اجرا مانع قبلی بوده و محتوای همین برنامه ساده اجرا شده. در پروژه واقعی، داشتن بیت x هنوز به‌تنهایی کافی نیست؛ فایل باید سالم باشه و محدودیت‌هایی مثل Mount هم می‌تونن روی اجرا اثر بذارن.

مرحله چهارم : مجوز پوشه در لینوکس رو جدا بررسی کنیم

حالا یک Permission denied در لینوکس از نوع دیگه می‌سازیم. به فایل یادداشت اجازه خواندن می‌دیم، اما اجازه عبور از پوشه notes رو برای مالک موقتاً برمی‌داریم. در نتیجه cat باید نتونه به فایل برسه، حتی اگر خود فایل خواندنی باشه. این تست رو با کاربر عادی انجام بده و مرحله بعدیِ بازگردانی مجوز رو پشت گوش ننداز.

chmod 600 "$LAB/project/notes/client-note.txt"
chmod u-x "$LAB/project/notes"
cat "$LAB/project/notes/client-note.txt"

توی این بخش از مجوز فایل در لینوکس، همین که پیام خطا رو دیدی، با chmod u+x اجازه عبور از پوشه رو برگردون و دوباره فایل رو بخون. برگردوندن وضعیت آزمایش به حالت سالم، بخشی از خود تمرینه. اگر قبل از بازگردانی دسترسی ترمینال رو بستی، با همون حساب مالک می‌تونی مجوز پوشه رو دوباره اصلاح کنی؛ فقط مسیر دقیق LAB رو باید پیدا کنی.

chmod u+x "$LAB/project/notes"
cat "$LAB/project/notes/client-note.txt"

اگر با وجود حذف بیت x باز هم فایل خونده شد، فرض نکن دستورها غلط هستن. اول بررسی کن با کاربر root یا قابلیتی که کنترل‌های معمول رو دور می‌زنه کار نمی‌کنی. سیاست ACL یا ویژگی فایل‌سیستم هم ممکنه شرایط رو متفاوت کنه. نتایج این آزمایش برای کاربر معمولی روی فایل‌سیستم لینوکسی طراحی شده‌ان.

مرحله پنجم : فایل فقط‌خواندنی رو حذف کن؛ چرا ممکنه؟

برای دیدن یک تفاوت دیگه، یک فایل کاملاً بی‌ارزش داخل پوشه delivery می‌سازیم و مجوزش رو 400 می‌کنیم. بعد فقط همون فایل رو حذف می‌کنیم، نه هیچ فایل دیگه‌ای. والد فایل هنوز قابل نوشتن و عبوره، پس انتظار داریم حذف موفق بشه. این آزمایش رو با نام فایل واقعی یا مسیر دلخواه خودت تکرار نکن.

if [[ -z "${LAB:-}" || "$LAB" != "$HOME"/nb-stopmotion.* || ! -d "$LAB/project/delivery" ]]; then
  printf '%s\n' 'مسیر LAB معتبر نیست؛ ابتدا مرحله ساخت محیط تمرین را اجرا کن.'
else
  printf "%s\n" "نسخه آزمایشی قابل حذف" > "$LAB/project/delivery/throwaway.txt"
  chmod 400 "$LAB/project/delivery/throwaway.txt"
  stat -c "%A | %a | %n" "$LAB/project/delivery/throwaway.txt"
  rm -f -- "$LAB/project/delivery/throwaway.txt"
  if test ! -e "$LAB/project/delivery/throwaway.txt"; then
    printf "%s\n" "temporary-file-removed"
  fi
fi

اگر خروجی temporary-file-removed رو دیدی، یک تفاوت مهم مجوز فایل در لینوکس رو لمس کردی: یعنی نام فایل آزمایشی حذف شده. اینجا chmod 400 خراب نشده؛ مجوز نوشتن روی خود فایل برای حذف نامش لازم نبود. این تفاوت برای مدیریت فایل در لینوکس و همچنین امنیت پوشه‌های اشتراکی خیلی مهمه. در یک پوشه دارای Sticky Bit یا محدودیت اضافه، نتیجه ممکنه فرق کنه.

آموزش chown؛ تغییر مالک فایل در لینوکس چه فرقی با chmod داره؟

یه سؤال پرتکرار اینه که chown چیست و چه فرقی با chmod داره؟ chmod درباره اجازه‌های دسترسیه، اما chown مالک فایل و در صورت تعیین، گروه مالک رو تغییر می‌ده. وقتی فایلی متعلق به حساب اشتباهه، اضافه کردن 777 بهش درمان تمیزی نیست. اول باید بدونی مالک فعلی، گروه مرتبط و کاربر اجراکننده سرویس کیا هستن.

برای آموزش chown، قالب دستور رو بشناس، اما نام‌های USER، GROUP و FILE توی نمونه بعدی فقط جای‌نگهدار هستن. بدون جایگزینی با حساب و فایل معتبر نباید فرمان مالکیت اجرا کنی. تغییر مالک به کاربر دیگه معمولاً به اختیار ویژه نیاز داره؛ ما عمداً این بخش رو روی حساب‌های واقعی سیستم تست نمی‌کنیم تا مالکیت چیزی دست‌کاری نشه.

# قالب دستورات، نه فرمان آماده اجرا روی سیستم واقعی:
# chown USER FILE
# chown USER:GROUP FILE
# chgrp GROUP FILE

اگر روزی لازم شد تغییر مالک فایل در لینوکس رو روی یک پروژه انجام بدی، اول با id هویت فرایند رو ببین و با stat مالک فایل رو بررسی کن. شاید اصلاً نیازی به جابه‌جایی مالک نباشه و بشه با گروه مناسب و مجوز محدود مسئله رو حل کرد. تصمیم رو بر اساس نیاز برنامه بگیر، نه صرفاً برای اینکه هشدار دسترسی ناپدید بشه.

گزینه -R برای تغییر مالکیت بازگشتی هم وجود داره، اما روی سرور زنده بسیار پرریسکه. یک مسیر اشتباه توی chown -R می‌تونه مالکیت تعداد زیادی فایل رو تغییر بده و سرویس‌ها رو از کار بندازه. توی این درس دستور مالکیت بازگشتی رو اجرا نمی‌کنیم؛ در عوض روش بررسی و تصمیم‌گیری درست رو یاد می‌گیریم.

چرا مجوز فایل‌های تازه با چیزی که انتظار داری فرق می‌کنه؟ آشنایی با umask

توی بحث مجوز فایل در لینوکس یه سؤال مهم داریم: چرا یک فایل جدید گاهی 644 می‌شه و گاهی 600؟ چون برنامه موقع ساخت فایل یک مجموعه مجوز درخواست می‌کنه و umask بیت‌هایی رو از اون درخواست حذف می‌کنه. برای فایل معمولی مبنای رایج 666 و برای پوشه 777 هست، اما مجوز نهایی ممکنه تحت تأثیر ACL پیش‌فرض و رفتار برنامه هم قرار بگیره. پس خود فایل رو با stat بررسی کن، نه با حدس.

ما ابتدای تمرین umask 077 گذاشتیم تا گروه و دیگران به‌صورت پیش‌فرض مجوزی از ساخت فایل‌ها نگیرن. به همین خاطر در محیط تست، فایل‌ها 600 و پوشه‌ها 700 شدن. این یک حالت آموزشی مشخصه؛ اگر مجوز واقعی روی سیستم تو متفاوت بود، دلیلش رو بررسی کن. یادت باشه umask مجوز فایل‌هایی رو که از قبل ساخته شدن تغییر نمی‌ده.

umask
stat -c "%a | %n" "$LAB/project/notes/client-note.txt" "$LAB/project/notes"

برای رفع مشکل دسترسی، umask 000 رو کورکورانه اجرا نکن. این کار می‌تونه فایل‌های بعدی رو برای گروه و دیگران بازتر از چیزی کنه که لازم داری. تنظیم مجوز مناسب باید از نیاز واقعی شروع بشه. توضیح دقیق این رفتار در مستندات رسمی GNU درباره umask هم اومده.

رفع خطای Permission denied در لینوکس؛ از کجا شروع کنیم؟

وقتی خطای دسترسی دیدی، اول این چهار سؤال رو جواب بده: چه فرمانی شکست خورده؟ با چه حسابی اجرا شده؟ روی کدوم فایل یا پوشه کار می‌کرده؟ دقیقاً چه حقی برای اون عملیات لازمه؟ این روش ساده برای رفع خطای Permission denied از اجرای تصادفی sudo chmod -R 777 خیلی بهتره. با تشخیص درست، فقط همون چیزی رو تغییر می‌دی که لازمه.

برای عیب‌یابی مجوز فایل در لینوکس روی مسیرهای طولانی، ابزار namei -l مفیده، چون مجوز تک‌تک اجزای مسیر رو نمایش می‌ده. این ابزار روی خیلی از توزیع‌ها موجوده، ولی نصب بودنش قطعی نیست؛ پس قبل از اجرا می‌تونیم با command -v بررسیش کنیم. اگر موجود نبود هم با ls -ld و stat می‌تونی مسیر رو مرحله‌به‌مرحله بررسی کنی.

if command -v namei >/dev/null 2>&1; then
  namei -l "$LAB/project/notes/client-note.txt"
else
  printf '%s\n' 'ابزار namei روی این سیستم نصب نیست.'
fi

اگر مجوزهای عادی درست به نظر می‌رسن ولی خطا هنوز پابرجاست، سراغ لایه‌های دیگه برو: ACL با getfacl، ویژگی‌های فایل با lsattr در فایل‌سیستم‌های پشتیبانی‌شده، حالت Mount و سیاست‌های SELinux یا AppArmor. مهمه که این ابزارها هم ممکنه روی سیستم نصب نباشن. هدف فعلی شناختن مسیر عیب‌یابیه؛ توضیح کامل این کنترل‌ها موضوع آموزش‌های پیشرفته‌تره.

علامت + کنار خروجی مجوزها می‌تونه خبر از ACL بده. همین‌طور اگر عضویت یک کاربر در گروه تغییر کرده ولی فرایند قدیمی هنوز با هویت قبل اجرا می‌شه، ممکنه رفتارش با نشست جدید فرق داشته باشه. برای همین وضعیت واقعی فرایند رو بررسی کن، نه فقط فایل /etc/group یا نتیجه یک دستور روی نشست دیگه.

چند اشتباه خطرناک که توی مدیریت Permission زیاد می‌بینیم

اشتباه اول : هر خطایی رو با sudo حل کنی

یکی از اشتباه‌ها موقع کار با مجوز فایل در لینوکس اینه که هر خطایی رو با sudo حل کنی. توی پروژه خودمون، فقط یک بیت اجرا کم بود و با chmod u+x مشکل برطرف شد. اجرای یک برنامه با دسترسی مدیریتی ممکنه خطای فعلی رو پنهان کنه، ولی هم‌زمان خطر اجرای کد ناخواسته رو بیشتر می‌کنه. اصل اینه که کمترين سطح دسترسی لازم رو انتخاب کنی.

اشتباه دوم : 777 رو «مجوز کامل و امن» بدونی

اشتباه دوم اینه که فکر کنی 777 یعنی «مجوز کامل و امن». این عدد در مدل معمول، راه نوشتن رو برای گروه و دیگران هم باز می‌کنه. اگر پوشه‌ای برای یک سرویس حساس استفاده می‌شه، چنین تغییری می‌تونه فایل‌های داخلش رو در معرض دست‌کاری قرار بده. پس قبل از استفاده از chmod 777 باید دقیقاً بفهمی چه کسی به چه عملیاتی نیاز داره.

اشتباه سوم : برای تمام فایل‌ها یک عدد ثابت بذاری

اشتباه سوم اینه که برای همه چیز یک عدد ثابت بذاری. فایل متنی معمولاً نیازی به اجرا نداره، یک اسکریپت شاید به x نیاز داشته باشه و پوشه برای قابل‌عبور بودن از همون بیت استفاده می‌کنه. اگر مجوزهای همه فایل‌های یک پروژه رو یک‌شکل کنی، ممکنه ناخواسته دسترسی اضافه بسازی یا بخشی از سیستم رو از کار بندازی.

اشتباه چهارم : فکر کنی مالک بودن یعنی همه‌چیز آزاد است

اشتباه چهارم اینه که مالک بودن رو معادل توانایی انجام هر کاری بدونی. مالک معمولاً می‌تونه بیت‌های مجوز فایل خودش رو تغییر بده، اما همچنان ممکنه فایل‌سیستم فقط‌خواندنی باشه یا یکی از پوشه‌های مسیر قابل عبور نباشه. تغییر مالک به حساب دیگه هم محدودیت جدا داره. همیشه نوع عملیات و شرایط محیط رو با هم ببین.

اشتباه پنجم : روی پوشه‌ها معنی x رو اشتباه بگیری

اشتباه پنجم هم قاطی کردن معنی x روی فایل و پوشه‌ست. روی فایل، مجوز اجرای مستقیم مطرحه؛ روی پوشه، اجازه عبور از مسیر. توی آزمایش بالا دیدی که برداشتن همین یک بیت از پوشه چطور جلوی خوندن فایل رو گرفت. اگر این تفاوت رو خوب جا بندازی، بخش بزرگی از عیب‌یابی مجوز پوشه در لینوکس برات قابل فهم‌تر می‌شه.

سه تمرین که بدون نگاه کردن به جواب حلشون کنی

تمرین اول: یک یادداشت خصوصی داری که فقط خودت باید بتونی بخونیش و تغییرش بدی. بین 600، 644 و 755 کدوم رو انتخاب می‌کنی؟ قبل از نگاه کردن به پاسخ، معنی هر سه رقم رو توضیح بده و نتیجه رو روی یک فایل جدید در پوشه آزمایشی بسنج. دقت کن اینجا داریم مجوز فایل رو بررسی می‌کنیم، نه مجوز پوشه.

تمرین دوم برای تثبیت مجوز فایل در لینوکس: پوشه‌ای برای انتشار فایل‌ها می‌خوای که مالک بتونه محتواش رو تغییر بده و بقیه اجازه دیدن نام و عبور داشته باشن. در یک مدل ساده، چه عددی نقطه شروع مناسبیه؟ حالا اگر فایل داخل پوشه 600 باشه، آیا باز بودن پوشه باعث می‌شه دیگران محتوای فایل رو بخونن؟ دلیلش رو با تفاوت مجوز فایل و پوشه توضیح بده.

تمرین سوم: اسکریپتت با bash preview.sh اجرا می‌شه، ولی ./preview.sh خطا می‌ده. سه فرضیه مطرح کن: شاید بیت اجرا وجود نداره، شاید مسیر قابل عبور نیست یا شاید فایل روی Mount با محدودیت اجراست. با stat، مسیر فعلی و خط اول اسکریپت شواهد جمع کن. بدون بررسی، هیچ مجوزی رو افزایش نده.

برای کنترل جواب‌ها: در تمرین اول معمولاً 600 مناسبه. در تمرین دوم، 755 برای خود پوشه یک نقطه شروع متداوله، اما محتوای فایل 600 همچنان برای دیگران قابل خواندن نیست. در تمرین سوم نبودن x یکی از احتمال‌های مهمه، ولی همه خطاهای اجرا به اون محدود نمی‌شن. اگر دلیل فنی متفاوتی پیدا کردی، شواهدش رو هم بنویس.

قبل از بستن ترمینال، چطور آزمایش رو جمع کنیم؟

آزمایش ما فقط داخل پوشه موقت خودت انجام شد. اگر دوست داری فایل‌ها رو نگه داری، مشکلی نیست. اگر هم می‌خوای بعداً پاکشون کنی، اول مسیر داخل LAB رو چاپ کن و یادت باشه کد پایانی مقدار قبلی umask رو هم بازمی‌گردونه؛ بعد و مطمئن شو همون پوشه تمرینیه. عمداً دستور حذف بازگشتی در اختیار نمی‌ذارم؛ تمرین کردن مجوز فایل در لینوکس به معنی عادت دادن دانشجو به حذف عجولانه نیست.

printf "LAB=%s\n" "$LAB"
ls -la "$LAB/project"
if [[ -n "${ORIGINAL_UMASK:-}" ]]; then
  umask "$ORIGINAL_UMASK"
  printf '%s\n' 'umask به مقدار قبلی برگردانده شد.'
fi

برای اینکه تمرین مجوز فایل در لینوکس بی‌خطر بمونه، اگر ترمینال رو بسته باشی، متغیر LAB در نشست جدید احتمالاً خالیه. بنابراین هیچ‌وقت یک مسیر حدسی رو جایگزینش نکن و فرمان حذف اجرا نکن. به‌خصوص در محیط واقعی، بررسی مقصد قبل از تغییر یکی از مهم‌ترین عادت‌های مدیریت فایل و امنیت لینوکسه.

بعد از یادگیری chmod و chown کجا باید بری؟

تا اینجا با مجوز فایل در لینوکس فقط به شکل یک عدد برخورد نکردی؛ با چند آزمایش دیدی چرا اسکریپت اجرا نمی‌شه، چطور اجازه عبور از پوشه روی خواندن فایل اثر می‌ذاره و چرا فایل فقط‌خواندنی هم ممکنه حذف بشه. این‌ها پایه تحلیل دسترسی در پروژه‌های واقعی هستن. برای عیب‌یابی کامل‌تر، بعداً باید کاربران، گروه‌ها، ACL و سیاست‌های امنیتی رو هم یاد بگیری.

حالا می‌تونی به مسیر رایگان Linux Essentials برگردی و تمرین درس‌های قبلی رو مرور کنی. اگر می‌خوای مباحث رو منسجم‌تر و با ویدیو و پروژه جلو ببری، پکیج آموزش Linux Essentials نابغه‌ها هم برای همین مسیر آماده شده. عجله‌ای برای دست‌کاری سرور واقعی نداریم؛ اول همین آزمایش‌های کوچک رو طوری انجام بده که خروجی‌شون رو واقعاً بفهمی.

سؤالات متداول مجوز فایل در لینوکس

منابع معتبر برای مطالعه بیشتر

برای بررسی فنی بیشتر، اهداف رسمی Linux Essentials در LPI بخش ۵٫۳، راهنمای GNU chmod، مستندات umask و مستندات بررسی مجوز مسیر در لینوکس منبع‌های معتبرن. این‌ها برای راستی‌آزمایی نکات فنی هستن؛ داستان استاپ‌موشن و تمرین‌های این درس، سناریوی آموزشی ساختگی همین مقاله‌ان.