Права доступа в Linux: как настроить chmod и chown без ошибок

В предыдущем материале мы освоили базовые команды Linux. Теперь разберём фундамент безопасности: модель прав доступа. Понимание chmod, chown, групп и специальных битов позволяет строить системы, где скрипты не рушат лог-файлы, а атака на веб-приложение не даёт злоумышленнику корневые права. Ниже — подробный, практический и живой гид, рассчитанный и на начинающих, и на тех, кто автоматизирует деплой на сотни серверов.

Зачем вообще нужны права

Любой объект файловой системы — это данные и метаданные. Права решают четыре ключевые задачи:

• Конфиденциальность — доступ получают только уполномоченные.
• Целостность — ошибочный скрипт не затрёт конфиг, к которому не имеет прав.
• Изоляция — взлом одного сервиса не равен компрометации всей ОС.
• Аудит — легко понять, кто владеет ресурсом и кого спрашивать при инциденте.

Без строгих разрешений DevOps-конвейер превращается в минное поле: umask 000 в одном шаге CI/CD — и приватные артефакты читаются из контейнера любым пользователем.

Пользователи и группы: основы модели безопасности

Linux связывает процессы с числовыми идентификаторами:

• UID (User ID) — владелец процесса или файла.
• GID (Group ID) — основная группа владельца.
• Дополнительные группы — список, расширяющий доступ без смены владельца.

Данные хранятся в /etc/passwd и /etc/group. UID 0 — это root, остальные делятся на системные (обычно 1–999) и «живые» (1000 +). Каждый дочерний процесс наследует UID/GID родителя, если только код не вызывает setuid()/setgid().

Три набора разрешений и девять классических битов

Каждый файл или каталог хранит 12 битов прав. Первые девять распределяются по трём категориям:

1. User (u) — владелец.
2. Group (g) — пользователи, входящие в основную группу файла.
3. Others (o) — все прочие аккаунты.

Действия кодируются значениями: read = 4, write = 2, execute = 1. Сумма трёх чисел для каждой категории образует «оценку» от 0 до 7:

• rw- = 6 — чтение и запись;
• r-x = 5 — чтение и выполнение;
• --- = 0 — никаких прав.

Команда ls -l показывает их в человекочитаемом виде:

-rwxr-x--- 1 alice devops 12288 Apr 30 10:41 deploy.sh
 |   | |  |
 |   | |  ----> группа-владелец
 |   | -------> пользователь-владелец
 |   ----------> права (u rwx, g r-x, o ---)
 --------------> тип (- файл, d каталог, l ссылка)

chmod: задаём и меняем права

Октальная (числовая) форма

Используется в скриптах, Ansible-плейбуках, Dockerfile:

chmod 640 secrets.yml   # владелец rw-, группа r--, остальные ---
 chmod 0755 /usr/local/bin/tool   # 0 — спецбиты не трогаем, 755 для ugo

Символьная форма

Удобна в интерактивной сессии:

• chmod u+x build.sh — позволяет владельцу запускать скрипт;
• chmod g-w,o-rwx *.conf — убирает запись у группы и все права у остальных;
• chmod a=rx public — всем разрешено только читать и проходить в каталог.

Три специальных бита: setuid, setgid, sticky

• setuid (4 000) — процесс запускается с UID владельца файла. Пример: /usr/bin/passwd, который позволяет обычным пользователям менять пароли.
• setgid (2 000) — аналогично для групп. На каталогах наследует группу для новых объектов.
• sticky (1 000) — запрещает удалять файл в общем каталоге, если вы не владелец. Классический пример — /tmp.

Установить: chmod 4775 script, снять: chmod u-s script.

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

Только root может отдавать файлы другому пользователю, но любой владелец вправе передавать объект другой группе, если входит в неё:

sudo chown bob:designers design.psd
 sudo chown -R root:admins /srv/api
 sudo chgrp marketing report*.odt

Для пакетных задач полезен флаг --reference: chown --reference=/var/www index.html копирует владельца/группу с эталонного файла.

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

Ядро берёт 666 для файла (777 для каталога) и вычитает umask. При значении 022 получаем 644/755. Проверьте своё значение:

$ umask
 0022

В CI-конвейере явно выставляйте umask 027, чтобы лог-файлы не были читаемы всеми.

ACL: когда u-g-o недостаточно

Access Control Lists дают тонкую грануляцию:

sudo setfacl -m u:qa:r /var/log/app
 getfacl /var/log/app

FACL-ы поддерживаются на ext4, xfs, btrfs и даже tmpfs. На виртуальных хостингах это спасает от хаоса, когда одним файлом должны пользоваться десятки сервисных аккаунтов.

Linux Capabilities: современная альтернатива setuid

Вместо полного UID 0 процессу можно дать ровно столько прав, сколько нужно:

# слушать 80/443 без root
 sudo setcap cap_net_bind_service+ep /usr/local/bin/myserver

Список 40+ возможностей описан в man 7 capabilities .

Практические сценарии

1. Безопасный каталог .ssh

chmod 700 ~/.ssh
 chmod 600 ~/.ssh/id_ed25519

OpenSSH откажется от ключа с более широкими правами.

2. Совместная разработка сайта

1. Создаём группу www-data, включаем nginx и php-fpm.
2. chown -R root:www-data /var/www/site
3. chmod 2755 /var/www/site — setgid обеспечивает наследование группы.

3. Ограничение прав бэкапа

useradd -r -s /usr/sbin/nologin backup
 setfacl -Rm u:backup:rx /etc
 setfacl -m default:u:backup:rx /etc

Демон бэкапа видит конфиги, но не может их менять.

4. Мини- аудит лишних setuid

#!/usr/bin/env bash
 find / -xdev -perm -4000 -type f 2>/dev/null | while read -r f; do
     echo "$(date +%F) SUSPECT $f" >> /var/log/setuid-check.log
 done

Типичные ошибки и как их избежать

• chmod 777 «для теста» — под производственной нагрузкой никто не вспомнит, что «временное» осталось.
• Копирование под root — файл меняет владельца; используйте --preserve=ownership в cp.
• Забытый setgid на скрипте — процесс запускается с привилегиями группы; лучше capabilities.
• umask 000 в Dockerfile — любой контейнер-peer увидит созданный файл.

Чек-лист при деплое

• Перед монтированием съёмных дисков задайте uid/​gid/​umask.
• Абстрагируйте роли через группы: веб, база, лог-аудит.
• Пройдитесь find /var/www -type f -perm /g=w,o=w и уберите лишнее.
• Поднимите SELinux/AppArmor-профиль для сервисов, если доступ к ядру не нужен.

Полезные ресурсы

• man chmod
• Arch Wiki: File Permissions & Attributes
• ACL Best Bits Calculator
• ExplainShell

Итоги

Модель прав Linux строится на простых числах, но открывает глубокие возможности: от классических rwx до cap_sys_admin. Освоив chmod, chown и группы, вы защищаете конфиденциальность, снижаете ущерб от уязвимостей и упрощаете совместную разработку. Делайте изоляцию принципом по умолчанию: минимум прав — максимум спокойствия.