فرمان chown در لینوکس؛ تغییر مالک و گروه فایل

chown مخفف change owner است و مالک کاربر و در صورت نیاز گروه یک فایل یا دایرکتوری را عوض می‌کند. وقتی سرویس با کاربر myapp اجرا می‌شود ولی داده مال root است، chmod به‌تنهایی کافی نیست؛ باید مالکیت را درست کنید. برعکس، chown بی‌برنامه روی درخت سیستم می‌تواند بسته و سرویس را بشکند.

صفحهٔ راهنمای chown نحو user، user:group و گزینه‌هایی مثل -R را شرح می‌دهد. chgrp فقط گروه را عوض می‌کند. این مقاله الگوهای امن برای اپ، ریسک بازگشتی، تعامل با کانتینر، و مسیر عیب‌یابی را می‌دهد. مدل rwx در ۱۴۷ و chmod در ۱۴۸ مکمل این‌اند.

روی بیشتر سیستم‌ها، فقط root می‌تواند مالک کاربر را به دیگری بدهد. این محدودیت از واگذاری مالکیت به‌عنوان راه فرار امنیتی جلوگیری می‌کند.

پاسخ کوتاه

برای دادن درخت داده به کاربر سرویس: chown -R myapp:myapp /var/lib/myapp با دامنهٔ دقیق. نحو user:group هر دو را یکجا ست می‌کند. قبل از -R دامنه را با find ببینید. chown را روی /usr یا /etc کور اجرا نکنید. بعد از تغییر، با sudo -u myapp تست خواندن/نوشتن انجام دهید.

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

نحو رایج

bash

# فقط مالک کاربر sudo chown myapp /var/lib/myapp # مالک و گروه sudo chown myapp:myapp /var/lib/myapp # فقط گروه (یا chgrp) sudo chown :deploy /opt/myapp sudo chgrp deploy /opt/myapp ls -ld /var/lib/myapp

اگر گروه را خالی بگذارید و فقط user: بدهید، رفتار به نسخه و گزینه وابسته است؛ صریح نوشتن user:group خواناتر و کم‌ریسک‌تر است. نام‌ها از passwd و group حل می‌شوند؛ uid عددی هم مجاز است و در کانتینر گاهی لازم.

چرا مالکیت غلط می‌شود؟

• استخراج آرشیو یا کپی با sudo که فایل را root می‌کند.
• اجرای اولیهٔ سرویس با root و ساخت فایل در مسیر داده.
• volume کانتینر با uid متفاوت از کاربر داخل Image.
• اسکریپت deploy که با کاربر دیگر از CI می‌آید.

پیشگیری: کاربر سرویس جدا، دایرکتوری داده از قبل با chown درست، و عدم اجرای روزمره با root. اگر مجبور به sudo شدید، بعدش مالکیت آرتیفکت را برگردانید.

chown -R و محدودهٔ امن

بازگشتی روی /var/lib/myapp معقول است اگر همان درخت فقط مال همان اپ باشد. بازگشتی روی / یا /var فاجعه‌خیز است. بعضی سیستم‌ها از chown -R روی پیوندهای نمادین رفتار خاصی دارند؛ man همان نسخه را بخوانید و از --dereference یا نبود آن آگاه باشید.

bash

# دامنه find /var/lib/myapp -maxdepth 2 -printf '%u:%g %p\n' | head sudo chown -R myapp:myapp /var/lib/myapp

هماهنگی با گروه و مجوز

گاهی به‌جای عوض کردن مالک به یک نفر، گروه مشترک deploy می‌گذارید و با chmod گروهی نوشتن می‌دهید. این برای چند انسان مفید است؛ برای سرویس runtime معمولاً مالک همان کاربر سرویس تمیزتر است. ترکیب اشتباه: مالک root، گروه root، و others باز — یعنی همه می‌توانند بخوانند بدون ردپای هویت.

کانتینر و uid عددی

داخل کانتینر کاربر myapp ممکن است uid ۷۰۰۱ باشد؛ روی میزبان همان عدد مال کس دیگری است. وقتی bind mount می‌کنید، آنچه روی دیسک میزبان دیده می‌شود همان uid عددی است. راه‌حل‌ها: یکسان‌سازی uid، یا chown در entrypoint با آگاهی، یا volumeهای named با کاربر سازگار. نادیده گرفتن این موضوع منبع کلاسیک denied در Docker است.

جدول تصمیم

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

• chown -R root:root روی خانهٔ کاربر برای «درست شدن».
• تغییر مالکیت کلیدهای SSH و شکستن دسترسی.
• فراموش کردن گروه بعد از عوض کردن فقط user.
• اجرای chown به‌جای درست کردن umask و کاربر سازنده.
• تغییر مالکیت فایل‌های بسته به‌جای نصب مجدد.

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

تفاوت chown و chmod چیست؟

chown هویت مالک/گروه را عوض می‌کند؛ chmod بیت‌های rwx را.

آیا کاربر عادی می‌تواند فایلش را به دیگری ببخشد؟

روی لینوکس معمولی معمولاً خیر؛ فقط root مالک کاربر را عوض می‌کند.

chown روی لینک نمادین چه می‌کند؟

بسته به گزینه‌ها ممکن است خود لینک یا هدف را تغییر دهد؛ قبل از -R روی درخت دارای لینک، man را چک کنید.

چرا بعد از chown هنوز خطای مجوز دارم؟

بیت‌ها، والدها، یا MAC. ls -l و namei را ببینید.

chgrp چه زمانی کافی است؟

وقتی مالک کاربر درست است و فقط گروه باید عوض شود.

تمرین

bash

sudo useradd -r -s /usr/sbin/nologin labapp || true sudo mkdir -p /var/tmp/labapp-data sudo chown labapp:labapp /var/tmp/labapp-data sudo -u labapp touch /var/tmp/labapp-data/ok ls -l /var/tmp/labapp-data

اگر touch با labapp موفق شد، مالکیت درست کار کرده است.

جمع‌بندی عملیاتی و هشدارهای میدانی (1)

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

بسیاری از حوادث از ترکیب عجله و sudo می‌آیند. وقتی denied می‌بینید، سه دقیقه برای namei و id و خواندن مستند همان سرویس سرمایه‌گذاری کنید. کوتاه‌کردن این سه دقیقه با ۷۷۷ یا chown -R روی درخت بزرگ، ساعت‌ها بازیابی می‌سازد. فرهنگ تیم باید پاداش عجلهٔ بی‌مدل را قطع کند.

در کانتینر و ابر، هویت عددی کاربر و نقشهٔ volume را در کنار مجوز کلاسیک ببینید. درست کردن فقط یک لایه و نادیده گرفتن لایهٔ دیگر، باگهای «گاهی کار می‌کند» می‌سازد که فقط در Production با دادهٔ واقعی دیده می‌شوند. محیط staging باید حداقل از نظر uid و مسیر volume شبیه باشد.

مستند کوتاه داخلی بهتر از حافظهٔ فردی است: کدام کاربر سرویس، کدام مسیر داده، کدام mode مطلوب، کدام Secret کجا می‌نشیند. این چهار خط را کنار واحد systemd نگه دارید تا onboarding و پاسخ حادثه سریع‌تر شود.

جمع‌بندی عملیاتی و هشدارهای میدانی (2)

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

بسیاری از حوادث از ترکیب عجله و sudo می‌آیند. وقتی denied می‌بینید، سه دقیقه برای namei و id و خواندن مستند همان سرویس سرمایه‌گذاری کنید. کوتاه‌کردن این سه دقیقه با ۷۷۷ یا chown -R روی درخت بزرگ، ساعت‌ها بازیابی می‌سازد. فرهنگ تیم باید پاداش عجلهٔ بی‌مدل را قطع کند.

در کانتینر و ابر، هویت عددی کاربر و نقشهٔ volume را در کنار مجوز کلاسیک ببینید. درست کردن فقط یک لایه و نادیده گرفتن لایهٔ دیگر، باگهای «گاهی کار می‌کند» می‌سازد که فقط در Production با دادهٔ واقعی دیده می‌شوند. محیط staging باید حداقل از نظر uid و مسیر volume شبیه باشد.

مستند کوتاه داخلی بهتر از حافظهٔ فردی است: کدام کاربر سرویس، کدام مسیر داده، کدام mode مطلوب، کدام Secret کجا می‌نشیند. این چهار خط را کنار واحد systemd نگه دارید تا onboarding و پاسخ حادثه سریع‌تر شود.

جمع‌بندی عملیاتی و هشدارهای میدانی (3)

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

بسیاری از حوادث از ترکیب عجله و sudo می‌آیند. وقتی denied می‌بینید، سه دقیقه برای namei و id و خواندن مستند همان سرویس سرمایه‌گذاری کنید. کوتاه‌کردن این سه دقیقه با ۷۷۷ یا chown -R روی درخت بزرگ، ساعت‌ها بازیابی می‌سازد. فرهنگ تیم باید پاداش عجلهٔ بی‌مدل را قطع کند.

در کانتینر و ابر، هویت عددی کاربر و نقشهٔ volume را در کنار مجوز کلاسیک ببینید. درست کردن فقط یک لایه و نادیده گرفتن لایهٔ دیگر، باگهای «گاهی کار می‌کند» می‌سازد که فقط در Production با دادهٔ واقعی دیده می‌شوند. محیط staging باید حداقل از نظر uid و مسیر volume شبیه باشد.

مستند کوتاه داخلی بهتر از حافظهٔ فردی است: کدام کاربر سرویس، کدام مسیر داده، کدام mode مطلوب، کدام Secret کجا می‌نشیند. این چهار خط را کنار واحد systemd نگه دارید تا onboarding و پاسخ حادثه سریع‌تر شود.

جمع‌بندی عملیاتی و هشدارهای میدانی (4)

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

بسیاری از حوادث از ترکیب عجله و sudo می‌آیند. وقتی denied می‌بینید، سه دقیقه برای namei و id و خواندن مستند همان سرویس سرمایه‌گذاری کنید. کوتاه‌کردن این سه دقیقه با ۷۷۷ یا chown -R روی درخت بزرگ، ساعت‌ها بازیابی می‌سازد. فرهنگ تیم باید پاداش عجلهٔ بی‌مدل را قطع کند.

در کانتینر و ابر، هویت عددی کاربر و نقشهٔ volume را در کنار مجوز کلاسیک ببینید. درست کردن فقط یک لایه و نادیده گرفتن لایهٔ دیگر، باگهای «گاهی کار می‌کند» می‌سازد که فقط در Production با دادهٔ واقعی دیده می‌شوند. محیط staging باید حداقل از نظر uid و مسیر volume شبیه باشد.

مستند کوتاه داخلی بهتر از حافظهٔ فردی است: کدام کاربر سرویس، کدام مسیر داده، کدام mode مطلوب، کدام Secret کجا می‌نشیند. این چهار خط را کنار واحد systemd نگه دارید تا onboarding و پاسخ حادثه سریع‌تر شود.

جمع‌بندی عملیاتی و هشدارهای میدانی (5)

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

بسیاری از حوادث از ترکیب عجله و sudo می‌آیند. وقتی denied می‌بینید، سه دقیقه برای namei و id و خواندن مستند همان سرویس سرمایه‌گذاری کنید. کوتاه‌کردن این سه دقیقه با ۷۷۷ یا chown -R روی درخت بزرگ، ساعت‌ها بازیابی می‌سازد. فرهنگ تیم باید پاداش عجلهٔ بی‌مدل را قطع کند.

در کانتینر و ابر، هویت عددی کاربر و نقشهٔ volume را در کنار مجوز کلاسیک ببینید. درست کردن فقط یک لایه و نادیده گرفتن لایهٔ دیگر، باگهای «گاهی کار می‌کند» می‌سازد که فقط در Production با دادهٔ واقعی دیده می‌شوند. محیط staging باید حداقل از نظر uid و مسیر volume شبیه باشد.

مستند کوتاه داخلی بهتر از حافظهٔ فردی است: کدام کاربر سرویس، کدام مسیر داده، کدام mode مطلوب، کدام Secret کجا می‌نشیند. این چهار خط را کنار واحد systemd نگه دارید تا onboarding و پاسخ حادثه سریع‌تر شود.

خلاصه

chown مالکیت را با هویت سرویس هم‌تراز می‌کند. دامنه را محدود کنید، با گروه و chmod هماهنگ کنید، و در کانتینر uid را جدی بگیرید. قدم بعد: دسترسی ممتاز را با sudo محدود و قابل‌حسابرسی کنید.

منابع و مراجع

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