Права на файли Linux: chmod, chown, SUID та ACL

Права доступу до файлів — фундаментальний механізм безпеки Linux. Неправильні права можуть призвести до витоку конфігів із паролями або дозволити зловмиснику виконувати код.

Числова нотація chmod

find /var/www -type f -exec chmod 644 {} \;
find /var/www -type d -exec chmod 755 {} \;
chmod u+x script.sh
chmod g-w config.php
chown -R www-data:www-data /var/www/site/

Символьна нотація і типові помилки

Символьний запис змінює права відносно поточних, а не задає їх заново цілком: chmod u+x додає право на виконання власнику, не чіпаючи права групи та інших. Це зручніше за числову нотацію, коли потрібно змінити один біт, не з'ясовуючи заздалегідь поточне значення решти.

Літери u, g, o та a означають власника (user), групу (group), інших (others) і всіх одразу (all); знаки +, - та = додають, прибирають або задають права точно. Наприклад, chmod go=r файл задасть групі та іншим рівно право на читання, яким би не було попереднє значення.

Помилка: chmod -R 777 як швидке рішення

Рекурсивний 777 на весь каталог сайту «щоб нарешті запрацювало» відкриває запис у файли будь-якому користувачу системи, включно з веб-сервером інших сайтів на тому самому хостингу і будь-яким процесом, що отримає доступ до системи. Правильний шлях — знайти, кому реально не вистачає прав (зазвичай це власник процесу веб-сервера), і видати права точково через chown або ACL, а не всім підряд.

Помилка: однакові права для файлів і каталогів

Право на виконання (x) у каталогу означає право заходити всередину і відкривати файли за іменем — це не те саме, що запуск програми, як для файлу. Каталог із правами 644 замість 755 не дає зайти в нього навіть за правильних прав на файли всередині, а файл зі скриптом із правами 755, коли потрібно було 644, дозволяє його запуск, якщо веб-сервер налаштований виконувати файли за розширенням.

Спеціальні біти: SUID, SGID, Sticky

# SUID — запуск із правами власника файлу
chmod u+s /usr/bin/program  # chmod 4755
# ls: -rwsr-xr-x

# SGID — успадкування групи директорії
chmod g+s /shared/dir  # chmod 2755

# Sticky bit — лише власник видаляє файл
chmod +t /tmp  # chmod 1777
# ls: drwxrwxrwt

# Знайти SUID-файли (потенційна загроза)
find / -perm -4000 -type f 2>/dev/null

ACL — розширені права

apt install acl -y
setfacl -m u:deploy:rw /var/www/config.php
setfacl -Rm g:devteam:rwx /var/www/project/
getfacl /var/www/config.php
setfacl -b /var/www/config.php  # Видалити ACL

chmod чи ACL: що обрати

Коли ACL не спрацює

• Файлова система змонтована без опції acl — більшість сучасних ext4 вмикають її за замовчуванням, але старі записи в /etc/fstab або мережеві монтування можуть її не задавати явно.
• Деякі мережеві файлові системи і старі версії NFS підтримують ACL обмежено або не підтримують зовсім — права застосовуються лише на рівні звичайного chmod.
• Архіватори та інструменти копіювання без спеціальних прапорців (наприклад, звичайний cp без --preserve в окремих випадках) можуть не переносити ACL разом із файлом — перевіряйте getfacl після перенесення важливих файлів на нове місце.

Перевірка результату

1. Виконайте stat -c "%a %U %G" /var/www/site/config.php — числові права і власник мають збігатися з тим, що ви задавали.
2. Для ACL виконайте getfacl файл і переконайтеся, що потрібний запис user: чи group: присутній у виводі.
3. Спробуйте зайти під непривілейованим користувачем і прочитати файл із правами 600 від іншого власника — доступ має бути заборонений.
4. Після рекурсивної зміни прав перевірте вибірково кілька файлів і каталогів через ls -la, а не лише каталог верхнього рівня — рекурсивні команди інколи зупиняються на файлах із нестандартними іменами.

Права файлів — лише один рівень захисту сервера; спостереження за тим, хто і коли їх змінював, розбирає стаття аудит подій через auditd, а додаткове розмежування доступу на рівні процесів — налаштування SELinux і AppArmor.