محتوای آموزشی وبلاگ نت‌آرام
به نظر می‌رسد برای یک کاربر یا گروه اجازه نوشتن روی فایل داده‌اید، اما برنامه هنوز
Permission denied می‌گیرد. ممکن است مجوز یکی از پوشه‌های مسیر مانع عبور باشد، برنامه با کاربر دیگری اجرا شود یا فهرست دسترسی تکمیلی فایل، یعنی ACL، مجوز مؤثر را محدود کرده باشد. دیدن یک خط rw- به‌تنهایی ثابت نمی‌کند همان کاربر واقعاً می‌تواند در فایل بنویسد.در این راهنما اول هویت پردازش و مسیر را پیدا می‌کنیم، بعد خروجی
getfacl و نقش mask را با یک نمونه می‌خوانیم و پیش از هر تغییر، اثر آن را آزمایش می‌کنیم. دستورها برای مدیر سرور لینوکسی با دسترسی لازم هستند؛ در هاست اشتراکی معمولاً باید از ابزار مجاز پنل یا پشتیبانی استفاده کنید. مثال‌ها را روی فایل حساس و بدون شناخت سرویس کپی نکنید.۱. کاربر و مسیر واقعی را پیدا کنید
در گزارش خطا، مسیر کامل فایل و نام سرویسی که خطا داده را بخوانید. فرض این مقاله فایل نمونه
کد / دستور/srv/example/app.log و کاربر فرضی writer است؛ هر دو را با مقادیر واقعی خود جایگزین کنید. روی سرویس systemd، این فرمان حساب پیکربندی‌شده را نشان می‌دهد:sudo systemctl show myapp.service -p User -p Group -p SupplementaryGroups
نام
کد / دستورmyapp.service نمونه است. خالی‌بودن یک مقدار الزاماً به معنی همان حسابی نیست که تصور می‌کنید؛ تعریف سرویس، روش اجرا و در صورت نیاز هویت پردازش زنده را هم ببینید. برای حساب واقعی:id writer
ls -ld /srv /srv/example
ls -l /srv/example/app.log
id شناسه و گروه‌های کاربر را نشان می‌دهد و دو فرمان بعد مجوز پوشه‌ها و فایل را فهرست می‌کنند. برای رسیدن به فایل، کاربر به اجازه عبور یا x در پوشه‌های مسیر نیاز دارد؛ اجازه نوشتن روی خود فایل بدون امکان عبور از پوشه‌های بالاتر کافی نیست. اگر namei روی سرور موجود است، این دستور اجزای مسیر را یکجا نشان می‌دهد:namei -l /srv/example/app.log
این خروجی یک دید اولیه از مجوزهای معمول است؛ ACL تکمیلی و سیاست‌های امنیتی دیگری مانند SELinux را نیز ممکن است لازم باشد جدا ببینید.
۲. ACL فعلی را بخوانید
اگر دستور
کد / دستورgetfacl نصب و فایل‌سیستم از ACL پشتیبانی می‌کند، اجرا کنید:getfacl -p /srv/example/app.log
getfacl -p /srv/example
گزینه
-p مسیر کامل را در خروجی نگه می‌دارد. علامت + کنار مجوزهای نمایش‌داده‌شده با ls -l می‌تواند نشانه وجود ACL تکمیلی باشد. اگر فرمان پیدا نشد یا فایل‌سیستم از این قابلیت پشتیبانی نمی‌کند، روش نصب یا تنظیم آن به توزیع و دسترسی مدیر بستگی دارد؛ خروجی نداشتن را به‌تنهایی دلیل مشکل فرض نکنید.یک خروجی ساده ممکن است چنین باشد:
کد / دستورuser::rw-
user:writer:rw- #effective:r--
group::r--
mask::r--
other::---
خط دوم برای کاربر نام‌برده اجازه خواندن و نوشتن درخواست کرده، اما توضیح
effective:r-- می‌گوید اثر فعلی آن فقط خواندن است. دلیل در این مثال mask::r-- است. ماسک مانند سقف برخی مجوزهای ACL عمل می‌کند: برای کاربرهای نام‌برده و گروه‌های مشمول، اجازه مؤثر از تقاطع اجازه آن ورودی و ماسک به دست می‌آید. ماسک جای مجوز مالک فایل یا other را به همان شکل نمی‌گیرد.توجه کنید که اگر حساب مورد بررسی مالک فایل باشد، قاعده انتخاب ورودی می‌تواند متفاوت از کاربر نام‌برده باشد. همچنین عضو بودن در گروه و مجوز مسیرهای بالاتر بر نتیجه اثر دارند. به همین دلیل خروجی را با هویت واقعی برنامه مقایسه کنید، نه با نامی که فقط در مثال آمده است.
۳. قبل از تغییر، دسترسی مؤثر همه ورودی‌ها را ببینید
اگر در مثال ما قرار است
writer بتواند در فایل بنویسد، تغییر ماسک از r-- به rw- ممکن است این مشکل را رفع کند؛ اما ماسک فقط برای این یک کاربر نیست. ممکن است گروه‌ها یا کاربران نام‌برده دیگری هم با همان تغییر، اجازه نوشتن مؤثر بگیرند. ابتدا تمام ورودی‌های ACL را بررسی کنید و تنها وقتی ادامه دهید که افزایش دسترسی همه آن‌ها مورد تأیید و متناسب با کار سرویس است.از تنظیم فعلی یک نسخه خصوصی داشته باشید. نمونه زیر در پوشه خانه کاربر اجراکننده ذخیره می‌کند؛ مطمئن شوید این پوشه خصوصی و فضای آن کافی است:
کد / دستورumask 077
mkdir -p "$HOME/acl-backups"
getfacl -p /srv/example/app.log > "$HOME/acl-backups/app-log-before.acl"
اگر فایل پشتیبان همنام قبلی دارید، نام تازه‌ای انتخاب کنید تا نسخه قبلی بازنویسی نشود. محتوای این فایل می‌تواند نام حساب‌ها و مسیرها را نشان دهد. قبل از هر بازیابی احتمالی، مسیر داخل پشتیبان و اثر بازیابی مالک و گروه را بررسی کنید؛ دستور بازگردانی یک مجموعه بزرگ ACL را بدون شناخت اجرا نکنید.
در نسخه‌هایی از
کد / دستورsetfacl که گزینه آزمایش را دارند، می‌توانید نتیجه پیشنهادی تغییر ماسک را بدون اعمال ببینید:setfacl --test -m m::rw- /srv/example/app.log
خروجی پیشنهادی را با وضعیت قبلی و دسترسی لازم هر گروه مقایسه کنید. اگر گزینه آزمایش در سیستم شما موجود نیست، با نسخه مورد تأیید سیستم یا یک فایل آزمایشی مجزا تمرین کنید. تغییر
chmod روی بخش گروه نیز می‌تواند ماسک ACL را تغییر دهد؛ بنابراین تکرار کورکورانه chmod ممکن است نتیجه را تغییر دهد، نه اینکه علت را روشن کند.۴. فقط پس از تأیید، تغییر محدود را اعمال کنید
اگر خروجی مرحله قبل تأیید کرد که گسترده‌ترشدن ماسک برای سایر ورودی‌ها مشکلی ندارد و این واقعاً همان فایل است، نمونه تغییر برای همین مورد چنین است:
کد / دستورsudo setfacl -m m::rw- /srv/example/app.log
getfacl -p /srv/example/app.log
فرمان اول ماسک را تغییر می‌دهد و دومی نتیجه واقعی را نشان می‌دهد. این دستور یک راه‌حل عمومی برای همه
Permission deniedها نیست. اگر کاربر نام‌برده در ورودی خودش اصلاً w نداشته باشد، افزودن w به ماسک به‌تنهایی برای او اجازه نوشتن نمی‌سازد. برعکس، افزودن یا تغییر ورودی نام‌برده با برخی حالت‌های setfacl می‌تواند ماسک را هم دوباره محاسبه کند؛ نتیجه همه ورودی‌ها را بعد از تغییر دوباره بخوانید.برای آزمایش دسترسی حساب فرضی، بدون تغییر محتوا:
کد / دستورsudo -u writer test -w /srv/example/app.log && echo writable || echo not-writable
این آزمون باید با حساب واقعی سرویس و دسترسی مدیریتی مجاز انجام شود. سپس خود برنامه را به روش معمول و با یک عملیات بی‌خطر امتحان کنید. اگر هنوز دسترسی رد می‌شود، ACL و مجوز هر پوشه مسیر، حالت فقط‌خواندنی فایل‌سیستم و گزارش SELinux یا محدودیت سرویس را جدا بررسی کنید. موفقیت
test به معنی سالم بودن همه عملیات برنامه نیست.اگر تغییر نتیجه نامطلوب داشت، با استفاده از نسخه مستندشده قبلی و فقط برای همان مسیر، تنظیم را به حالت تأییدشده برگردانید و دوباره آزمون کنید. از
chmod -R 777 و حذف سراسری ACLها برای رفع عجولانه خودداری کنید. برای همراهی در رسیدگی به مجوزها و نگهداری، صفحه خدمات مدیریت سرور نت‌آرام را ببینید. قواعد کامل‌تر در راهنمای ACL لینوکس و مستند setfacl آمده است.اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام