403 همیشه یک علت ندارد. امشب policy وب، دسترسی لینوکس و label امنیتی را جدا می‌سنجیم تا مشکل با chmod گسترده پنهان نشود.

این جلسه بخشی از دورهٔ انجین‌اکس در ۵۰ شب است. قرارداد آزمایشگاه، مسیرها و روال اعمال تغییر در راهنمای دوره آمده است.

محیط: سایت ثابت www؛ NGINX_USER در Debian/Ubuntu معمولاً www-data و در Alma/Rocky nginx است.

حق خواندن و عبور#

namei -l /var/www/nginx-lab/public/index.html
sudo -u "$NGINX_USER" test -r /var/www/nginx-lab/public/index.html
ps -eo user,pid,ppid,args

فرمان test در موفقیت چیزی چاپ نمی‌کند؛ کد خروج را با echo $? ببین. کارگر باید فایل را بخواند و از پوشه‌های والد عبور کند. برای فایل ثابت lab، پوشهٔ 755 و فایل 644 با مالک root کافی است؛ Nginx نیاز به نوشتن کد ندارد.

در RHEL:

sudo semanage fcontext -a -t httpd_sys_content_t '/var/www/nginx-lab(/.*)?'
sudo restorecon -Rv /var/www/nginx-lab
ls -Zd /var/www/nginx-lab/public
sudo ausearch -m AVC -ts recent

اگر نگاشت وجود دارد، ابتدا آن را با semanage fcontext -l بررسی و در صورت نیاز با -m ویرایش کن. policy وب از typeهای دارای نام httpd استفاده می‌کند؛ این نام به معنی نیاز به سرویس Apache نیست. chcon جای نگاشت پایدار را نمی‌گیرد.

شاهد خطا#

از کلاینت درخواست بفرست و /var/log/nginx/www-error.log را ببین. خطای permission denied، نبودن فایل و ممنوع بودن index سرنخ‌های متفاوت‌اند. محتوای عمومی دیگر را برای آزمون secret تغییر نده.

آزمایش و بازگشت: روی index آزمایشی، مجوز خواندن را موقتاً بردار، نتیجه را ثبت و به 644 برگردان. 777 یا مالک کردن کل سایت به runtime انتخاب مناسبی نیست. پوشهٔ نوشتنی WordPress در بخش مربوط جدا label و ownership خواهد گرفت.

منبع: SELinux و Nginx در RHEL .