Права доступу на хостингу: chmod, chown та інші заклинання, від яких залежить ваш сайт

Ви коли-небудь бачили білий екран замість свого сайту і панічно писали в підтримку хостера, а відповідь була лаконічна: «Перевірте права доступу до файлів»? Якщо так - ласкаво просимо до клубу. Якщо ні - ви або везунчик, або просто ще не доросли до цього моменту. Права доступу до файлів і каталогів - це той самий невидимий шар безпеки, про який ніхто не думає, поки щось не зламається. А коли зламається, виявляється, що один невірно виставлений chmod перетворив ваш сайт на прохідний двір для будь-якого бота. Давайте розберемося раз і назавжди, як працюють ці магічні цифри, навіщо потрібен chown і чому 777 - це не лотерейний виграш, а квиток на катастрофу.

Що таке права доступу і чому вони схожі на замки у квартирі

Уявіть, що ваш сервер - це багатоквартирний будинок. У кожній квартирі (файлі) живе щось цінне: конфігурація бази даних, скрипти, зображення, CSS-стилі. Права доступу - це замки на дверях. Хтось має ключ від усього будинку (root), хтось - лише від своєї квартири (user), а хтось може тільки зазирнути через вічко (read-only для групи чи публіки).

У Linux-системах, на яких працює переважна більшість хостингів, кожен файл і каталог має три групи дозволів:

• Owner (власник) - той, хто створив файл або кому його «приписали»
• Group (група) - набір користувачів, об'єднаних адміністратором
• Others (інші) - усі решта, включаючи ваших відвідувачів і, на жаль, ботів

Для кожної групи існує три типи дозволів: r (read - читання), w (write - запис), x (execute - виконання). Саме з них складається та трицифрова комбінація, яку ви бачите в cPanel, FileZilla або терміналі.

Числова магія chmod: розшифровуємо 644, 755 і страшну 777

Отже, кожен дозвіл має числове значення: r = 4, w = 2, x = 1. Складаємо їх для кожної групи і отримуємо ту саму трицифрову комбінацію. Коли ви бачите chmod 644, це означає: власник може читати і писати (4+2=6), група може тільки читати (4), інші теж тільки читають (4).

Звучить просто? Так і є. Але диявол, як завжди, у деталях.

Запам'ятайте як мантру: 644 для файлів, 755 для каталогів. Це золотий стандарт, який підходить для 90% випадків на shared-хостингу. Все інше - виняткові ситуації, які потребують розуміння, а не копіпасту з форуму.

Чому chmod 777 - це запрошення для зловмисника

Я бачив десятки випадків, коли початківці, натрапивши на помилку «Permission denied», просто ставили 777 на весь каталог. Працює? Так. Безпечно? Ні. Це як зняти вхідні двері квартири, бо загубили ключ. Технічно ви більше не матимете проблем з доступом. Але і злодій теж не матиме.

«Chmod 777 - це єдина річ, яку я забороняю своїм студентам навіть на тестовому сервері. Якщо ви звикнете до 777 на деві, ви рано чи пізно забудете прибрати це на проді.» - Денис Давиденко, інженер з безпеки, OSCP

Що відбувається, коли файл має дозвіл 777? Будь-який процес на сервері може його прочитати, змінити або запустити. На shared-хостингу, де десятки сайтів живуть поруч, вразливий скрипт сусіда теоретично може дістатися до ваших файлів. А якщо мова про upload-директорію з правами 777, будь-який бот може завантажити туди шкідливий PHP-файл і отримати повний контроль над вашим акаунтом.

Реальна історія: один мій клієнт тримав на shared-хостингу інтернет-магазин. Після оновлення плагіна каталог uploads «злетів» на 777. Через 11 днів Google заблокував сайт - у каталозі виявили 340 файлів з фішинговими сторінками. Повернення в індекс зайняло два місяці. Два місяці без трафіку. Подумайте про це.

chown і chgrp: хто насправді володіє вашими файлами

Права доступу - це тільки половина картини. Друга половина - хто рахується як «власник». Тут з'являються команди chown (change owner) і chgrp (change group).

На типовому shared-хостингу власник ваших файлів - це ваш обліковий запис. Але коли в гру вступає PHP, починаються нюанси. Залежно від конфігурації сервера, PHP-процес може працювати від імені:

1. Вашого користувача (suPHP, PHP-FPM з окремим пулом) - найбезпечніший варіант
2. Користувача www-data або apache (mod_php) - класичний, але менш безпечний підхід
3. Спеціального користувача nobody - зустрічається рідше, але буває

Чому це важливо? Тому що якщо PHP працює від www-data, а файли належать вашому юзеру, то для запису в файл потрібні групові або публічні дозволи на запис. А це - дірка. Натомість, якщо хостер налаштував PHP-FPM з пулом для кожного акаунта, PHP працює від вашого імені, і 644/755 достатньо для всього.

Як перевірити? Створіть простий PHP-файл:

<?php echo exec('whoami'); ?>

Відкрийте його в браузері. Побачите ім'я користувача, від якого працює PHP. Якщо це ваш логін - чудово. Якщо www-data або apache - уважно стежте за правами каталогів, куди PHP має писати.

Покрокова інструкція: виставляємо правильні права за 7 хвилин

Досить теорії. Ось конкретний рецепт, який працює на переважній більшості хостингів з cPanel або SSH-доступом.

Через SSH (термінал):

1. Підключіться до сервера: ssh username@yourserver.com
2. Перейдіть у кореневу директорію сайту: cd ~/public_html
3. Встановіть права 755 для всіх каталогів: find . -type d -exec chmod 755 {} ;
4. Встановіть права 644 для всіх файлів: find . -type f -exec chmod 644 {} ;
5. Захистіть конфігураційний файл: chmod 600 wp-config.php (для WordPress) або chmod 600 .env (для Laravel)
6. Перевірте upload-директорію: вона має бути 755, не більше
7. Перевірте результат: ls -la покаже поточні права у форматі rwxr-xr-x

Через cPanel (File Manager):

Клікніть правою кнопкою на файл або каталог, виберіть «Change Permissions», виставте потрібні галочки. Для масової зміни - виділіть кілька об'єктів. Просто, але повільніше, ніж через SSH.

Порада, яка зекономить нерви: після будь-якого масового оновлення CMS або плагінів перевіряйте права доступу. Деякі плагіни (особливо для кешування та SEO) люблять «тихо» змінювати chmod на каталоги.

Типові помилки, які я бачу щотижня

За роки практики я зібрав колекцію граблів, на які наступають і новачки, і досвідчені адміни. Ось топ-5:

• 777 на upload - вже обговорили, але повторю: це дірка розміром з ворота гаража
• 644 на каталоги - каталоги потребують біт виконання (x), інакше сервер не зможе «увійти» в них. Результат: 403 Forbidden
• Забутий .htaccess з правами 666 - зловмисник може переписати правила і перенаправити весь ваш трафік на фішинговий сайт
• Ігнорування chown після розпаковки архіву - якщо ви завантажили бекап через root і розпакували, файли можуть належати root, а не вашому юзеру. PHP не зможе до них писати
• Однакові права для всього - конфіг з паролем бази даних і картинка логотипу не повинні мати однакові дозволи. Точка

Автоматизація: щоб не перевіряти вручну щоразу

Якщо ви керуєте кількома сайтами або просто не хочете забувати про перевірку, ось простий Bash-скрипт, який можна повісити на cron:

#!/bin/bash
cd ~/public_html
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;
chmod 600 wp-config.php
echo "Permissions fixed at $(date)" >> ~/permissions.log

Додайте його в cron, наприклад, раз на добу. Так ви матимете гарантію, що навіть після автоматичного оновлення плагіну права повернуться до норми. Це не параноя - це гігієна. Як мити руки перед їжею. Не бачите бактерій, але вони є.

Можна піти далі і налаштувати моніторинг через inotifywait, який буде відстежувати зміни прав у реальному часі та відправляти сповіщення. Але це вже рівень VPS або dedicated - на shared-хостингу такі інструменти зазвичай недоступні.

Ось що мене завжди дивує: люди витрачають годину на вибір шаблону сайту, але жодної хвилини - на перевірку прав доступу. При цьому неправильний chmod може коштувати вам репутації, позицій у Google і навіть грошей. Тож ось вам питання на десерт: ви впевнені, що прямо зараз на вашому сервері немає файлу з правами 777, про який ви забули три роки тому?