Права доступа к файлам в Linux: chmod, chown и безопасность

Три символа — r, w, x — и число 755. Для кого-то это просто набор букв и цифр, для кого-то — язык, на котором Linux разговаривает о безопасности. Модель прав доступа linux унаследована от UNIX 1970-х, её придумал Кен Томпсон, и с тех пор принцип не изменился: каждому файлу — владелец, группа и набор разрешений. Просто? Да. Достаточно? Если знать нюансы — вполне. А нюансов хватает: специальные биты, расширенные списки доступа, атрибуты файловой системы, взаимодействие с MAC-системами.

Поговорим о том, как работают chmod и chown, где прячутся подводные камни, и почему chmod 777 — это не решение, а начало проблем.

Что показывает ls -l

Когда Вы набираете ls -l, терминал выдаёт что-то вроде:

Первый символ — тип (- файл, d директория, l симлинк). Дальше — три тройки: права владельца (rwx), группы (r-x) и остальных (r--). Владелец admin, группа webdev. Вот и вся карта доступа.

Числовой формат chmod основан на восьмеричной системе, где каждое разрешение — это бит: read = 4, write = 2, execute = 1. Складываем: rwx = 4+2+1 = 7, r-x = 4+0+1 = 5, r-- = 4+0+0 = 4. Получается 754. Один раз разберёшься с арифметикой — и символьные обозначения станут не нужны.

Два формата chmod — символьный и октальный — делают одно и то же, но октальный быстрее для тех, кто привык считать в уме. Символьный удобнее, когда нужно изменить конкретный бит: chmod g+w config.yml добавит запись для группы, не трогая остальное.

chown: смена владельца и группы

Команда chown меняет владельца и группу файла. Синтаксис прост:

Флаг -R применяет изменения рекурсивно. И здесь кроется ловушка: chown -R по директории с симлинками может уйти далеко за пределы того, что Вы хотели изменить. Если внутри /var/www/html есть симлинк на /etc, поздравляю — Вы только что поменяли владельца системных конфигов. Флаг --no-dereference (или -h) не следует за симлинками и спасает от таких сюрпризов.

Ещё один тонкий момент: chown можно использовать и для смены только группы — chown :developers file.txt. Но для этой операции есть выделенная команда chgrp, которая читается понятнее в скриптах. Кому как удобнее — функционально разницы нет.

Частая ошибка в продакшене — запустить chown -R от root на весь раздел. На файловой системе с миллионом файлов это занимает минуты, блокирует I/O и может вызвать дёрганье связанных сервисов. Если нужно массовое изменение владельца, делайте это в maintenance-окне или используйте find с -exec для порционной обработки.

Типичная задача — настройка безопасности файлов ubuntu для веб-сервера:

Эта связка гарантирует, что веб-сервер сможет читать файлы и заходить в директории, но не будет записывать куда попало.

Почему chmod 777 — это капитуляция

Когда что-то не работает, появляется соблазн выставить chmod 777 и «разобраться потом». Потом обычно не наступает, а 777 означает, что любой процесс в системе может читать, писать и выполнять файл. Включая скомпрометированный PHP-скрипт, вредоносный cron или случайно запущенный процесс.

На рабочих серверах 777 — это прямое нарушение принципа наименьших привилегий. Если атакующий получает выполнение кода через уязвимость в веб-приложении, он работает от имени www-data. С правами 777 ему доступна запись куда угодно: можно подменить скрипты, залить веб-шелл, модифицировать конфиги базы данных. С 644 на файлах и 755 на директориях тот же www-data может только читать — а записать или выполнить что-то произвольное уже не получится.

Вместо 777 разберитесь, какому пользователю и группе нужен доступ. Обычно проблема решается правильным chown и разумными 755/644. Если приложению нужно писать в определённую директорию (загрузка файлов, кэш, сессии), создайте отдельную директорию с 770 и добавьте веб-сервер в нужную группу.

SUID, SGID и Sticky Bit: привилегии без root

Помимо стандартных девяти бит, Linux поддерживает три специальных бита, которые меняют поведение файлов и директорий.

SUID (Set User ID) — бит, при котором исполняемый файл запускается с правами владельца, а не того, кто его вызвал. Классический пример — /bin/passwd:

Буква s вместо x в пользовательском блоке — признак SUID. Благодаря ему обычный пользователь может менять свой пароль, хотя файл /etc/shadow доступен только root. Удобно — но если SUID стоит на скомпрометированном бинарнике, атакующий получает root-шелл. Ещё один нюанс: SUID работает только для бинарников. На скриптах (bash, python) ядро Linux игнорирует этот бит — и это сознательное решение, потому что интерпретируемые языки создают слишком большую поверхность атаки. Регулярный аудит SUID-файлов — обязательная процедура:

SGID (Set Group ID) на директории работает иначе: все файлы, созданные внутри такой директории, наследуют её группу, а не группу пользователя. Это незаменимо для совместной работы:

mkdir /opt/project
chown :developers /opt/project
chmod 2775 /opt/project

Теперь любой файл, созданный в /opt/project, автоматически принадлежит группе developers. Без SGID каждому пришлось бы вручную менять группу через chown — смена владельца руками на каждом файле утомляет.

Sticky Bit на директории запрещает удалять чужие файлы, даже если права на запись есть. Директория /tmp — каноничный пример:

ls -ld /tmp
drwxrwxrwt 15 root root 4096 Feb 15 10:00 /tmp

Буква t в конце означает sticky bit. Без него /tmp превратился бы в хаос — любой пользователь мог бы удалять файлы любого другого пользователя.

chattr: защита, которую не обходит даже root

Команды chmod и chown управляют доступом, но от root они не защитят — суперпользователь может изменить любые разрешения. Утилита chattr работает на уровне атрибутов файловой системы (ext2/ext3/ext4, btrfs, XFS) и добавляет защиту, которую root не обойдёт без явного снятия атрибута.

# Сделать файл неизменяемым (immutable)
chattr +i /etc/resolv.conf
# Попытка изменить — отказ
echo "nameserver 8.8.8.8" >> /etc/resolv.conf
# bash: /etc/resolv.conf: Operation not permitted

# Разрешить только дописывание (append-only) — идеально для логов
chattr +a /var/log/audit.log

Атрибут +i делает файл неизменяемым: его нельзя удалить, переименовать, изменить или создать на него жёсткую ссылку. Работает на ext2/ext3/ext4, btrfs и XFS — то есть практически на любой файловой системе, которую Вы встретите на Linux-серверах. Атрибут +a разрешает только добавление данных — идеально для файлов журналов, которые должны расти, но не должны быть подчищены. Если кто-то (или что-то) попытается обрезать лог через > или удалить строки, система вернёт «Operation not permitted».

Нюанс: chattr — не серебряная пуля. Злоумышленник с root-доступом снимет атрибут командой chattr -i. Но от случайных ошибок, автоматических обновлений и скриптов, которые лезут куда не надо, — защищает надёжно. Для усиления можно ограничить доступ к самой утилите chattr или убрать capability CAP_LINUX_IMMUTABLE.

ACL: когда трёх категорий мало

Классическая модель «владелец-группа-остальные» покрывает 90% задач. Оставшиеся 10% — когда нужно дать доступ конкретному пользователю без смены группы, или когда у директории два отдела-потребителя с разными уровнями доступа.

Для этого в Linux есть POSIX ACL — Access Control Lists, управляемые через setfacl и getfacl. ACL работают поверх стандартных разрешений и позволяют назначить права конкретному пользователю или группе без перестройки всей структуры владения:

# Дать пользователю deployer доступ rw к конфигу
setfacl -m u:deployer:rw /etc/app/config.yml

# Дать группе auditors доступ только на чтение
setfacl -m g:auditors:r /var/log/app.log

# Проверить ACL
getfacl /etc/app/config.yml

Файл с ACL помечается знаком + в результатах ls -l:
-rw-rw-r--+ 1 root root 2048 Jan 10 config.yml

Файл с ACL помечается знаком + в результатах ls -l:

-rw-rw-r--+ 1 root root 2048 Jan 10 config.yml

ACL поддерживают наследование через default ACL: все новые файлы в директории получат заданные разрешения автоматически. Это особенно полезно для проектных директорий, где постоянно появляются новые файлы.

Для рекурсивного применения ACL на существующие файлы используйте флаг -R:

Одно предупреждение: ACL усложняют отладку. Когда у файла есть и стандартные разрешения, и ACL, итоговый доступ определяется через маску (mask), и результат может удивить. Маска ограничивает эффективные права всех именованных пользователей и групп — если маска r--, то даже ACL с rwx даст только чтение. Если Вы видите + в ls -l и не понимаете, почему доступ работает не так — getfacl покажет полную картину.

umask: права по умолчанию

Когда процесс создаёт файл, ядро применяет маску umask для определения начальных разрешений. Стандартный umask 022 даёт файлам 644 (rw-r--r--), директориям — 755 (rwxr-xr-x). Логика: из базовых 666 (файлы) или 777 (директории) побитово вычитается umask.

Проверить текущую маску можно командой umask без аргументов. Часто администраторы забывают, что umask наследуется дочерними процессами. Если в .bashrc стоит umask 077, все запущенные из этой сессии процессы создают файлы, недоступные никому кроме владельца. Звучит безопасно, но на деле ломает веб-серверы, которым нужно читать статику, и CI/CD-пайплайны, где артефакты должны быть доступны нескольким пользователям.

Проблема возникает и в скриптах. Многие не устанавливают umask явно, и если скрипт запущен от пользователя с umask 000, созданные файлы получат 666 — запись для всех. Решение:

Для systemd-сервисов umask задаётся через UMask= в unit-файле. Для контейнеров Docker — через --security-opt или securityContext в Kubernetes.

Автоматизация и аудит

На одном сервере права можно настроить руками. На десятках — уже нет. Ansible, Salt, Puppet — любой из этих инструментов умеет декларативно описывать права и отслеживать дрифт. Главное преимущество — идемпотентность: таск применяется повторно без побочных эффектов, а при отклонении от желаемого состояния система возвращает всё на место.

Пример Ansible-таска:

Для мониторинга изменений есть auditd — подсистема ядра, которая логирует обращения к файлам:

Логи auditd пишутся в /var/log/audit/audit.log и содержат информацию о том, кто, когда и что изменил. Для серверов под ФЗ-152 или PCI DSS это обязательная часть compliance — аудиторы спросят, как Вы отслеживаете изменения прав на файлы с персональными данными. Если хотите понять, как выглядит этот процесс в целом, почитайте про подготовку серверной инфраструктуры к ИБ-аудиту — там разобраны типичные требования и чек-листы.

А для compliance-проверок (ФЗ-152, PCI DSS) пригодится find — пожалуй, самая недооценённая утилита для аудита прав. Вот набор команд, который стоит добавить в еженедельный cron:

Результаты стоит сохранять и сравнивать между запусками. Если в пятницу SUID-файлов было 47, а в понедельник стало 48 — это повод разобраться, откуда взялся новый.

SELinux и AppArmor: следующий рубеж

Базовые права доступа linux работают по принципу DAC — Discretionary Access Control. Владелец решает, кому дать доступ. Для enterprise-среды этого мало: скомпрометированный процесс с правами www-data получит доступ ко всему, что доступно www-data.

SELinux (RHEL, CentOS, Fedora) и AppArmor (Ubuntu, Debian, SUSE) реализуют MAC — Mandatory Access Control. Здесь политики задаёт администратор, и даже root не может их обойти без изменения политики. Если chmod определяет, кто может обратиться к файлу, то SELinux/AppArmor определяют, какой процесс может это сделать — и это принципиально другой уровень контроля.

SELinux и AppArmor не заменяют chmod и chown — они работают поверх. Базовая проверка DAC проходит первой, затем MAC-система решает, допустить ли операцию. Два уровня вместо одного. Для Ubuntu безопасность файлов ubuntu усиливается связкой AppArmor + стандартные разрешения: AppArmor ограничивает, какие файлы может читать конкретный демон (например, MySQL не полезет в /home), а chmod определяет, кто из пользователей имеет доступ к тем же файлам.

Права в контейнерах

Docker по умолчанию запускает процессы от root — и это проблема. Если контейнер скомпрометирован, атакующий получает root внутри контейнера, а при неправильной конфигурации — и на хосте. Принцип тот же, что и на обычном сервере: выделите непривилегированного пользователя и дайте ему только те права, которые нужны.

Здесь --chown в COPY критичен: без него файлы внутри образа принадлежат root, и процесс от appuser не сможет их прочитать. Частая ошибка — копировать файлы, а потом удивляться «Permission denied» при запуске контейнера.

В Kubernetes безопасность настраивается через securityContext:

Параметр fsGroup определяет группу для смонтированных томов — аналог chown для файловых систем pod'а. А readOnlyRootFilesystem не даёт процессу записывать за пределами выделенных томов. Без этого параметра скомпрометированный контейнер может создавать файлы в корневой ФС — а это путь к эскалации привилегий.

Отдельный момент — umask внутри контейнеров. По умолчанию он наследуется от среды выполнения, и если containerd или Docker daemon запущены с umask 0022, все контейнеры получат его же. Для критичных сервисов имеет смысл задавать umask явно в entrypoint-скрипте.

Вместо финальных слов

Система прав в Linux — это не про запоминание числовых комбинаций. Это про понимание того, кто и зачем обращается к файлу. chmod задаёт разрешения, chown определяет владельца, ACL расширяют модель для нестандартных случаев, chattr защищает от случайных (и не только) изменений, а SELinux/AppArmor добавляют обязательный контроль.

Все эти инструменты — слои одной системы безопасности. По отдельности каждый из них решает свою задачу, вместе — создают эшелонированную оборону. chmod без правильного chown бесполезен. ACL без понимания маски запутает. SUID без аудита — бомба замедленного действия.

Если вынести из этой статьи одну мысль — пусть будет такая: не выставляйте 777 и не запускайте всё от root. Разберитесь, какие минимальные права нужны процессу, и дайте ему ровно столько. Принцип наименьших привилегий придумали не для красоты — он реально работает. А find / -perm /4000 стоит запускать хотя бы раз в неделю — для собственного спокойствия.