Права на файлы 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.