3. Пользователи, права и безопасность

UID/GID, права (setuid/setgid/sticky), ACL, sudo, основы PAM/SELinux/AppArmor и практическая диагностика «permission denied» без chmod 777.

UID и GID

UID (User ID) и GID (Group ID) — числовые идентификаторы пользователя и основной группы. Ядро оперирует именно ими; имена (root, www-data) резолвятся через /etc/passwd и /etc/group. Процесс выполняется с UID/GID своего пользователя и наследует их дочерним процессам (если не используется setuid/setgid или смена пользователя через setuid-программы). Проверка: id, id -u, id -g.

chmod и биты setuid / setgid / sticky

Классические права (chmod)

Три категории: владелец (u), группа (g), остальные (o). Три права: read (r), write (w), execute (x). Для каталога x означает право входить и читать имена файлов. Установка: chmod 755 file (rwxr-xr-x), chmod u+x file и т.д.

setuid, setgid, sticky

Дополнительные биты в той же тройке разрядов (четвёртый разряд в числовой записи):

setuid (4) — исполняемый файл выполняется с правами владельца файла, а не запустившего. Пример: /usr/bin/passwd (чтобы менять /etc/shadow). Риск: уязвимость в setuid-программе даёт права владельца. Смотреть: ls -l — в позиции x у владельца стоит s.
setgid (2) — для файла: выполнение с GID группы файла. Для каталога: новые файлы в нём наследуют группу каталога (удобно для общих каталогов). Пример: chmod g+s /shared.
sticky (1) — только для каталога (например, /tmp): удалить/переименовать файл может только владелец файла или root. Без sticky любой с записью в каталог мог бы удалить чужие файлы.

Примеры: chmod 4755 binary (setuid), chmod 2775 /shared (setgid на каталог), chmod 1777 /tmp (sticky).

ACL (Access Control Lists)

ACL даёт права на файл или каталог для конкретного пользователя или группы сверх классической тройки u/g/o. Не нужно создавать группу «только для этого каталога» — можно выдать права одному пользователю.

Установка и просмотр

# Установить право: пользователь john — rwx на каталог
setfacl -m u:john:rwx /path/to/dir

# Группа dev — r-x
setfacl -m g:dev:r-x /path/to/dir

# Права по умолчанию для новых файлов в каталоге (default ACL)
setfacl -m d:u:john:rwx /path/to/dir

# Просмотр ACL
getfacl /path/to/dir

ФС должна поддерживать ACL (ext4, XFS — да); при монтировании не должно быть опции noacl. Разобрать «permission denied» часто можно, добавив запись в ACL, не открывая права всему миру (o) и не делая chmod 777.

sudo

sudo позволяет выполнять команды от имени другого пользователя (по умолчанию root) с проверкой прав в /etc/sudoers (и файлах в /etc/sudoers.d/). Важно не давать полный NOPASSWD без необходимости и понимать среду выполнения.

NOPASSWD и secure_path

NOPASSWD — для указанной команды пароль не запрашивается. Удобно для скриптов и CI, но увеличивает риск при компрометации учётной записи. Задаётся в sudoers: user ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx.
secure_path — переменная PATH, подставляемая при выполнении sudo (чтобы привилегированные команды не подменялись программами из домашнего каталога пользователя). Смотреть: sudo sudo -V (Secure_path).

Правки sudoers только через visudo — проверка синтаксиса перед сохранением.

PAM (на уровне понимания)

PAM (Pluggable Authentication Modules) — слой между приложением и механизмами аутентификации. Модули в /etc/pam.d/ определяют, как проверять пароль, ограничивать доступ (limit), вести логи и т.д. При проблемах «не могу залогиниться» или «sudo не принимает пароль» часто смотрят конфиги в /etc/pam.d/ и логи (auth.log, journalctl). Для DevOps достаточно понимать: аутентификация и учёт проходят через PAM; смена модулей или неправильный порядок могут заблокировать вход.

SELinux и AppArmor (концепции и базовое использование)

SELinux

SELinux (Security-Enhanced Linux) — принудительный контроль доступа (MAC): политика в ядре разрешает или запрещает действия (процесс → объект) по меткам (типам и ролям). Файлы и процессы имеют контекст (например, system_u:object_r:httpd_sys_content_t). Даже при правах 777 доступ может быть запрещён политикой. Команды:

# Контекст файла и процесса
ls -Z /var/www/html
ps -Z -p <pid>

# Временно перевести в permissive (логировать, но не запрещать) для диагностики
sudo setenforce 0
# Включить обратно
sudo setenforce 1

При «permission denied» при нормальных правах и ACL проверять: getenforce, контексты и аудит (ausearch, /var/log/audit). Временное решение для разработки — setenforce 0 (не для production без плана).

AppArmor

AppArmor — альтернатива SELinux в части профилей приложений: профиль описывает, какие пути и возможности разрешены процессу. Используется в Ubuntu, SUSE. Профили в /etc/apparmor.d/. Статус: aa-status; перезагрузка профиля: sudo systemctl reload apparmor. При отказе в доступе смотреть логи и профиль (путь не в списке разрешённых — добавить в профиль и перезагрузить).

Практика

Настроить доступ к каталогу через ACL

# Допустим, нужно дать пользователю deploy право писать в /var/www
sudo setfacl -m u:deploy:rwx /var/www
sudo setfacl -m d:u:deploy:rwx /var/www   # для новых файлов внутри

# Проверка
getfacl /var/www

Так один пользователь получает доступ без смены владельца каталога и без chmod 777.

Разобрать «permission denied» без chmod 777

Последовательность:

Кто и что — от какого пользователя/процесса и к какому объекту (файл, каталог, сокет). Проверить: ls -la, ps -u, откуда запущен процесс.
Классические права — хватает ли u/g/o? Владелец и группа файла: совпадают ли с процессом или его группами (groups)?
Для каталога — на путь к файлу нужен x на каждом каталоге в пути; на каталог, где создаётся файл, — w.
ACL — getfacl по объекту; при необходимости добавить запись для пользователя/группы процесса.
SELinux/AppArmor — если включены, проверить контексты и аудит; при необходимости скорректировать политику или контекст (restorecon, chcon — осторожно) или временно permissive для воспроизведения.

Итог: устранить причину (нужный владелец/группа, ACL, политика), а не открывать 777.

!!! tip "Практика"

chmod 777 — последний resort и только для изолированных тестовых сред. В production всегда выяснять: какой процесс, какой объект, чего не хватает (права, группа, ACL, MAC).

Паттерны и антипаттерны

Паттерн	Описание
Минимальные права	Давать только нужные r/w/x и только нужным пользователям/группам или через ACL.
Группа для общего каталога + setgid	Новые файлы наследуют группу каталога; не нужно вручную chgrp.
Проверять SELinux/AppArmor при странном denied	Сначала getenforce/aa-status, потом контексты и логи.

Антипаттерн	Почему плохо	Что делать
chmod 777 «чтобы заработало»	Любой пользователь может изменить или удалить файлы.	Найти причину (владелец, группа, ACL, MAC) и выдать точечные права.
Отключать SELinux без разбора	Теряется защита; проблема может быть в одной политике.	Смотреть audit, править политику или контексты; setenforce 0 только для диагностики.