فرمان chmod در لینوکس؛ تغییر مجوز فایل و دایرکتوری

chmod مخفف change mode است: بیت‌های rwx و در صورت نیاز بیت‌های خاص را روی فایل یا دایرکتوری عوض می‌کند. مالک فایل معمولاً می‌تواند chmod بزند؛ root تقریباً همیشه. اگر مدل مقالهٔ ۱۴۷ را نخوانده‌اید، اول معنی r و w و x روی دایرکتوری در برابر فایل را بفهمید — وگرنه اعداد جادویی حفظ می‌کنید و در Production بدهی امنیتی می‌کارید.

دو شیوهٔ رایج وجود دارد: عددی اکتال (مثل ۷۵۵) و نمادین (مثل u+x یا g-w). هر دو در صفحهٔ راهنمای chmod مستند شده‌اند. این مقاله الگوهای امن روزمره، تفاوت فایل و دایرکتوری، بازگشتی خطرناک، تعامل با umask، و تلهٔ ۷۷۷ را پوشش می‌دهد تا به‌جای کپی از اولین نتیجهٔ جستجو، تصمیم آگاهانه بگیرید.

chmod مالکیت را عوض نمی‌کند. اگر گروه یا کاربر اشتباه است، chown یا chgrp لازم دارید. قاطی کردن این دو ابزار یکی از پرتکرارترین سردرگمی‌های تازه‌واردهاست.

پاسخ کوتاه

برای فایل متنی یا کانفیگ معمولاً ۶۴۴، برای اسکریپت یا باینری کاربر ۷۵۵، برای Secret خصوصی ۶۰۰، برای دایرکتوری‌های عادی ۷۵۵ یا ۷۵۰. با شکل نمادین می‌توانید فقط یک بیت را روشن یا خاموش کنید بدون بازنویسی بقیه. chmod -R قدرتمند و خطرناک است؛ روی / یا خانه بدون فیلتر و بدون درک درخت نزنید. همیشه بعد از تغییر، با همان کاربر سرویس تست کنید نه با root.

chmod مشکل مالکیت را حل نمی‌کند. اگر گروه اشتباه است، chown یا chgrp لازم دارید نه فقط ۷۷۵.

شکل عددی (اکتال)

سه رقم رایج به ترتیب owner، group، others هستند. هر رقم جمع ۴ (r) + ۲ (w) + ۱ (x) است. رقم چهارم اختیاری برای بیت‌های خاص (setuid/setgid/sticky) هم وجود دارد که کمتر در کار روزمرهٔ اپ می‌آید ولی برای /tmp مهم است.

bash

chmod 644 README.md chmod 755 deploy.sh chmod 600 ~/.ssh/id_ed25519 chmod 700 ~/.ssh

حفظ کردن چند الگوی پرتکرار بهتر از improvise کردن هر بار است. جدول بالا را در یادداشت تیم بگذارید و انحراف‌ها را توضیح دهید.

شکل نمادین

چه کسانی: u (owner)، g (group)، o (others)، a (all). عمل: + اضافه، - حذف، = تنظیم دقیق آن دسته. مجوزها: r و w و x و برای خاص‌ها s و t.

bash

chmod u+x deploy.sh chmod go-w settings.ini chmod a-x script.sh chmod u=rw,g=r,o= notes.txt chmod g+s shared_dir chmod +t upload_dir

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

دایرکتوری و بیت اجرا

دایرکتوری بدون x برای شما قابل cd نیست و دسترسی به فایل داخلی با مسیر مستقیم هم ممکن است شکست بخورد. الگوی امن برای درخت وب:

bash

mkdir -p /var/www/myapp chmod 755 /var/www/myapp find /var/www/myapp -type f -exec chmod 644 {} \; find /var/www/myapp -type d -exec chmod 755 {} \;

جدا کردن type f و type d بهتر از chmod -R 755 روی مخلوط فایل و پوشه است؛ وگرنه به فایل‌های غیراجرایی هم x می‌دهید. گاهی بی‌ضرر است، گاهی سیاست امنیتی یا ابزار اسکَن را گیج می‌کند.

chmod -R؛ قدرت و پشیمانی

• روی درخت پروژهٔ خودتان با مسیر مطلق دقیق و بکاپ ذهنی OK است.
• روی /، /etc، /var بدون خشک‌کردن فکر و بدون پنجرهٔ نگهداری نزنید.
• ترکیب با sudo خطر را چندبرابر می‌کند چون محدودیت مالک را برمی‌دارد.
• قبل از -R، یک find خشک برای دیدن دامنه اجرا کنید.

bash

# دامنه را ببینید find /var/www/myapp -maxdepth 2 -print # سپس هدفمند find /var/www/myapp -type d -exec chmod 755 {} \;

داستان‌های واقعی Ops پر است از یک chmod -R اشتباه که SSH را شکست یا بسته را غیرقابل‌خواندن کرد. اگر مجبور به بازگشتی شدید، مسیر را دو بار بخوانید و از history بدون فکر بالا نیاورید.

رابطه با umask و فایل‌های جدید

chmod وضعیت فعلی را عوض می‌کند؛ umask روی فایل‌هایی که از این به بعد ساخته می‌شوند اثر می‌گذارد. اگر سرویس مدام فایل با مجوز گشاد می‌سازد، فقط chmod روی فایل‌های قدیمی کافی نیست — umask یا تنظیمات خود سرویس را درست کنید. در واحد systemd می‌توان UMask= گذاشت.

نمونه‌های عملی استقرار

کلید SSH کاربر: دایرکتوری .ssh باید ۷۰۰ و کلید خصوصی ۶۰۰ باشد؛ در غیر این صورت ssh ممکن است کلید را نادیده بگیرد. فایل env حاوی راز: ۶۰۰ با مالک کاربر سرویس. اسکریپت deploy که توسط همان کاربر اجرا می‌شود: ۷۵۰ اگر گروه عملیاتی باید اجرا کند، وگرنه ۷۰۰.

برای پوشهٔ آپلود کاربر نهایی: نه ۷۷۷. بهتر است مالک سرویس، گروه محدود، و در صورت نیاز sticky تا کاربران همدیگر را پاک نکنند. اگر وب‌سرور و اپ کاربر جدا دارند، گروه مشترک و ۶۴۰/۷۵۰ غالباً از باز کردن others تمیزتر است.

اشتباه‌های رایج

• chmod 777 -R به‌عنوان اولین واکنش به denied.
• اعمال ۷۵۵ بازگشتی روی فایل‌های داده.
• فراموش کردن که w روی دایرکتوری اجازهٔ حذف فایل دیگران را می‌دهد.
• chmod روی لینک بدون فهم اینکه معمولاً هدف مهم است.
• تغییر مجوز فایل‌های بسته زیر /usr به‌جای اصلاح نصب.
• تست موفقیت با کاربر root بعد از chmod.

سوالات متداول

تفاوت ۶۷۵۵ و ۷۵۵ چیست؟

رقم چهارم بیت‌های خاص را می‌گذارد. برای کار روزمرهٔ اپ معمولاً همان سه رقم کافی است؛ setuid را بدون دلیل روشن نکنید.

چرا بعد از chmod هنوز denied دارم؟

مالکیت اشتباه، نبود x روی والد، یا MAC. namei -l و id را ببینید؛ chown را در ۱۴۹.

آیا chmod روی فایل باز اثر فوری دارد؟

مجوز روی عملیات بعدی چک می‌شود؛ جزئیات به نوع دسترسی باز بستگی دارد. سرویس را در صورت نیاز reload کنید و با کاربر سرویس دوباره تست کنید.

symbolic بهتر است یا numeric؟

هر دو رسمی‌اند. برای تغییر جزئی symbolic؛ برای اعمال سیاست مشخص numeric خوانایی خوبی در مستند دارد.

چطور بیت اجرا را فقط برای مالک بگذارم؟

chmod u+x file یا با اکتال مناسب مثل ۷۰۰/۷۵۰/۷۵۵ بسته به گروه و others.

چه زمانی chmod نکنید؟

وقتی مشکل از مسیر اشتباه، بستهٔ خراب، یا سیاست SELinux است، chmod فقط رد گمراه‌کننده می‌سازد. وقتی مالکیت غلط است، اول هویت را درست کنید. وقتی فایل باید از بسته بیاید، با مدیر بسته نصب کنید نه کپی دستی با مجوز تصادفی.

تمرین کوتاه

در مسیر آزمایشی، فایلی بسازید، با نمادین u+x بدهید، با اکتال ۶۴۴ برگردانید، بعد یک دایرکتوری بسازید و x را از others بردارید و اثر را با کاربر دوم ببینید. این تمرین را قبل از اولین chmod روی Production انجام دهید.

bash

cd /tmp && mkdir chmod-lab && cd chmod-lab echo ok > f.txt chmod u+x f.txt; ls -l f.txt chmod 644 f.txt mkdir d && chmod 751 d ls -ld d

سیاست مجوز در مخزن Infrastructure as Code

chmodهای دستی روی سرور زنده بدون ثبت در Ansible یا اسکریپت deploy، در بازسازی بعدی محو می‌شوند و تیم را به باستان‌شناسی نیمه‌شب وادار می‌کنند. بهتر است حالت مطلوب مسیرها را در کد زیرساخت بنویسید: مالک، گروه، mode. همان کد روی staging و production یکسان اجرا شود.

در review قالب‌های IaC، به دنبال modeهای ۷۷۷ و ۶۶۶ بگردید. گاهی برای «راه‌افتادن تست» وارد می‌شوند و همان‌طور به main می‌رسند. سیاست ساده: هر mode گشاد باید کامنت توجیه داشته باشد یا در چک خودکار رد شود.

برای درخت‌هایی که هم فایل و هم دایرکتوری دارند، دو وظیفهٔ جدا در IaC بهتر از یک chmod بازگشتی همه‌کاره است؛ همان الگوی find type را بازتاب می‌دهد و خوانایی را بالا می‌برد.

chmod و فایل‌های نسخه‌شده در Git

Git بیت اجرا را تا حدی نگه می‌دارد ولی مدل کامل مجوز یونیکسی را بازتولید نمی‌کند. فرض نکنید clone روی سرور همان ۶۰۰ لازم برای Secret را می‌دهد. Secret را در Git نگذارید؛ برای اسکریپت‌های اجرایی، در pipeline یک گام صریح chmod +x بگذارید تا وابسته به umask توسعه‌دهنده نباشید.

روی ویندوز و بعضی سیستم‌های فایل شبکه‌ای، بیت اجرا رفتار متفاوتی دارد. اگر تیم مختلط است، گام CI که مجوز را نرمال می‌کند جلوی «روی مک من اجرا می‌شد» را می‌گیرد.

هوک‌های Git و اسکریپت‌های local که به +x نیاز دارند باید در README مسیر آماده‌سازی داشته باشند، نه اینکه هر تازه‌وارد یک ساعت روی Permission denied بماند.

نکتهٔ تکمیلی عملی (1)

در کار واقعی، تغییر مجوز بدون مشاهدهٔ اثر ناقص است. بعد از هر chmod مهم، همان عملیات شکست‌خورده را با هویت درست تکرار کنید و خروجی را ثبت کنید. اگر در محیط تیمی کار می‌کنید، فرمان و نتیجه را در تیکت بنویسید تا نفر بعدی همان مسیر را دوباره اختراع نکند. این عادت ساده بیش از حفظ جدول اکتال از تکرار حادثه جلوگیری می‌کند و به مرور الگوهای امن تیم را شکل می‌دهد.

ابزارهای مانیتورینگ پیکربندی و اسکن آسیب‌پذیری گاهی modeهای مشکوک را گزارش می‌کنند. به‌جای نادیده گرفتن هشدار، تصمیم بگیرید: یا mode را درست کنید، یا استثنا را مستند کنید. استثناهای بی‌مستند در ممیزی بعدی هزینه می‌سازند. برای مسیرهای موقت آزمایشی، تاریخ انقضا بگذارید تا درخت ۷۷۷ آزمایشی تا ابد روی سرور نماند.

به خاطر بسپارید که کپی فایل با cp ممکن است مجوز را از منبع یا از umask بگیرد بسته به گزینه‌ها و سیستم. بعد از کپی Secret یا اسکریپت، ls -l را چک کنید. در انتقال با scp و rsync هم همین حساسیت وجود دارد؛ flagهای حفظ مجوز را فقط وقتی می‌فهمید چه می‌کنند فعال کنید.

نکتهٔ تکمیلی عملی (2)

در کار واقعی، تغییر مجوز بدون مشاهدهٔ اثر ناقص است. بعد از هر chmod مهم، همان عملیات شکست‌خورده را با هویت درست تکرار کنید و خروجی را ثبت کنید. اگر در محیط تیمی کار می‌کنید، فرمان و نتیجه را در تیکت بنویسید تا نفر بعدی همان مسیر را دوباره اختراع نکند. این عادت ساده بیش از حفظ جدول اکتال از تکرار حادثه جلوگیری می‌کند و به مرور الگوهای امن تیم را شکل می‌دهد.

ابزارهای مانیتورینگ پیکربندی و اسکن آسیب‌پذیری گاهی modeهای مشکوک را گزارش می‌کنند. به‌جای نادیده گرفتن هشدار، تصمیم بگیرید: یا mode را درست کنید، یا استثنا را مستند کنید. استثناهای بی‌مستند در ممیزی بعدی هزینه می‌سازند. برای مسیرهای موقت آزمایشی، تاریخ انقضا بگذارید تا درخت ۷۷۷ آزمایشی تا ابد روی سرور نماند.

به خاطر بسپارید که کپی فایل با cp ممکن است مجوز را از منبع یا از umask بگیرد بسته به گزینه‌ها و سیستم. بعد از کپی Secret یا اسکریپت، ls -l را چک کنید. در انتقال با scp و rsync هم همین حساسیت وجود دارد؛ flagهای حفظ مجوز را فقط وقتی می‌فهمید چه می‌کنند فعال کنید.

خلاصه

chmod ابزار تغییر بیت‌های مجوز است، نه درمان همهٔ deniedها. اکتال برای سیاست‌های ثابت، نمادین برای تغییر دقیق، و find جدا برای فایل و دایرکتوری امن‌تر از -R کور است. حداقل دسترسی را حفظ کنید و با کاربر واقعی سرویس تست کنید.

قدم بعد: مالکیت را با chown درست کنید، سپس sudo را طوری تنظیم کنید که برای chmodهای سیستمی ردپا بماند.

منابع و مراجع

• man7.org — chmod(1) — https://man7.org/linux/man-pages/man1/chmod.1.html
• man7.org — inode(7) — https://man7.org/linux/man-pages/man7/inode.7.html
• Ubuntu manpages — chmod(1) — https://manpages.ubuntu.com/manpages/noble/en/man1/chmod.1.html
• man7.org — credentials(7) — https://man7.org/linux/man-pages/man7/credentials.7.html
• POSIX chmod (opengroup) — https://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html