Система прав на файлы в Linux и SELinux

Зачем вообще нужна система прав

В Linux почти всё представлено как файл: обычные файлы, каталоги, устройства, сокеты, каналы. Поэтому контроль доступа к файлам — это базовый механизм безопасности всей системы.

Когда процесс пытается открыть файл, ядро проверяет:

1. кто запрашивает доступ — пользователь и его группы;
2. какие права стоят на объекте — обычные UNIX-права, ACL, специальные биты;
3. нет ли дополнительных ограничений — например, SELinux.

Из-за этого возможна ситуация:

• обычные права вроде бы разрешают доступ;
• но SELinux всё равно запрещает операцию.

Именно поэтому в Linux важно понимать две модели одновременно:

• классическую модель UNIX permissions;
• мандатную модель SELinux.

2. Три базовых права: r, w, x

Для обычного файла

r — read

Позволяет читать содержимое файла.

Пример:

• есть r → можно открыть файл через cat, less, редактор;
• нет r → содержимое прочитать нельзя.

w — write

Позволяет изменять содержимое файла.

Пример:

• есть w → можно редактировать файл;
• нет w → запись будет запрещена.

x — execute

Позволяет запускать файл как программу или скрипт.

Пример:

./backup.sh

Скрипт должен:

• иметь бит x;
• обычно содержать корректный shebang, например #!/bin/bash.

Важно: наличие r не означает наличие x, и наоборот.

3. Владелец, группа, остальные

Права задаются отдельно для трёх классов:

• u — user, владелец;
• g — group, группа;
• o — others, все остальные;
• a — all, все сразу.

Пример:

-rwxr-x---

Расшифровка:

• владелец: rwx
• группа: r-x
• остальные: ---

Если пользователь — владелец файла, применяются права владельца.
Иначе ядро проверяет, входит ли пользователь в группу файла.
Если нет — применяются права для остальных.

Важное уточнение

Это не суммирование по принципу «взяли лучшее отовсюду».
Система выбирает один релевантный класс:

1. владелец;
2. иначе группа;
3. иначе others.

5. Как смотреть права и владельцев

Базовые команды

ls -l
ls -ld directory
stat file
id
groups

Что полезно смотреть

ls -l

Показывает краткую информацию по файлам в каталоге.

ls -ld dir

Показывает права самого каталога, а не его содержимого.
Это частая ошибка новичков.

stat file

Даёт более подробную информацию:

• права в символьной и восьмеричной форме;
• UID/GID;
• время доступа/изменения;
• inode и так далее.

id

Показывает:

• UID пользователя;
• основную группу;
• дополнительные группы.

Это важно при диагностике «почему у меня нет доступа, хотя группа вроде правильная».

7. Как создаются права по умолчанию и что такое umask

Когда создаётся новый файл или каталог, права не берутся «из воздуха».
На них влияет umask — маска, которая отключает часть разрешений по умолчанию.

Типичные базовые значения

Обычно:

• файл создаётся как 666 (без execute);
• каталог — как 777.

Потом из них вычитается umask.

Пример с umask 022

• файл: 666 - 022 = 644
• каталог: 777 - 022 = 755

Пример с umask 027

• файл: 666 - 027 = 640
• каталог: 777 - 027 = 750

Посмотреть текущую маску

umask
umask -S

Практический смысл

Если в команде или приложении не задаются специальные права, именно umask определяет, насколько «открытыми» будут новые объекты.

Важный нюанс

umask не добавляет права, а только убирает.
Поэтому обычный файл при создании не получает x, даже если umask это не запрещает.

9. Специальные биты: setuid, setgid, sticky bit

Кроме обычных rwx, в Linux есть специальные биты.

9.2. setgid

На исполняемом файле

Процесс запускается с эффективным GID группы файла.

На каталоге

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

Пример:

drwxrws--- 2 max devs 4096 Apr 1 10:00 teamdir

Если у каталога teamdir выставлен setgid, то всё новое внутри будет принадлежать группе devs.

Это удобно для совместной работы команды.

Установка

chmod g+s dir
chmod 2775 dir

10. Что означают s, S, t, T

Если специальный бит установлен, но execute-бит отсутствует, увидишь заглавную букву:

• s — setuid/setgid + execute есть;
• S — setuid/setgid есть, execute нет;
• t — sticky + execute есть;
• T — sticky есть, execute нет.

Пример:

-rwSr--r--

Это означает: setuid выставлен, но файл не исполняемый. Обычно это бессмысленно или признак ошибки в настройке.

12. ACL: расширенные права доступа

Классическая модель owner/group/others проста, но иногда слишком груба.

Пример проблемы:

• файл принадлежит max;
• группа файла devs;
• нужно дать доступ ещё и пользователю alice, не меняя владельца и не создавая новую группу.

Для этого есть ACL (Access Control Lists).

Как понять, что на файле есть ACL

ls -l покажет +:

-rw-r-----+ 1 max devs 1250 Apr 1 10:15 report.txt

Посмотреть ACL

getfacl report.txt

Пример:

user::rw-
user:alice:r--
group::r--
mask::r--
other::---

Это значит:

• владелец max имеет rw-;
• пользователь alice дополнительно имеет r--;
• группа имеет r--;
• остальные — нет доступа.

Установить ACL

setfacl -m u:alice:r-- report.txt
setfacl -m g:testers:rwX shared_dir

Удалить ACL-запись

setfacl -x u:alice report.txt

Удалить все расширенные ACL

setfacl -b report.txt

Что такое mask в ACL

mask — это максимально допустимые права для:

• именованных пользователей ACL;
• именованных групп ACL;
• группы файла.

Это очень частый источник непонимания.

Пример:

user:alice:rwx
mask::r--

Формально для alice записано rwx, но эффективно работать будет только r--, потому что mask обрезает остальные права.

Права по умолчанию на каталоге

Можно задавать ACL по умолчанию для новых файлов внутри каталога:

setfacl -d -m g:devs:rwx project/

Это полезно в общих каталогах команды.

14. Root и ограничения root

Обычно root воспринимается как пользователь, который «может всё». В классической UNIX/DAC-модели это почти так.

Но есть нюансы:

• некоторые проверки всё равно завязаны на capabilities;
• файловая система может быть смонтирована с ограничениями;
• SELinux может запретить действие даже процессу, который запущен от root.

Это одна из причин, почему на системах с SELinux фраза «я же root» не всегда решает проблему.

16. DAC против MAC

DAC — классическая модель

Владелец файла может сам менять права на свой объект.
Это гибко, но не всегда безопасно.

Пример:

• пользователь сделал файл слишком открытым;
• сервис получил доступ к лишним данным.

MAC — обязательный контроль

Правила определяются централизованной политикой.
Процесс не может просто «разрешить себе всё» через chmod.

Это особенно полезно для сервисов:

• веб-сервер;
• база данных;
• DNS;
• контейнеры.

Даже если сервис взломали, SELinux ограничивает, куда он может лезть.

18. Режимы работы SELinux

Посмотреть режим:

getenforce
sestatus

Enforcing

Политика применяется реально. Запрещённые действия блокируются.

Permissive

SELinux ничего не блокирует, но пишет в лог, что было бы запрещено.
Удобно для диагностики.

Disabled

SELinux выключен.

Временно переключить режим

sudo setenforce 0   # permissive
sudo setenforce 1   # enforcing

Это временно, до перезагрузки.

Постоянная настройка

Обычно меняется в конфигурации SELinux, например:

/etc/selinux/config

Но просто выключать SELinux «чтобы заработало» — плохая практика.
Правильнее понять, что именно запрещено и почему.

20. Типичный пример с веб-сервером

Допустим, сайт лежит не в стандартном /var/www/html, а в /home/max/site.

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

/home/max/site/index.html
-rw-r--r--

Но Apache или Nginx всё равно не читает файл.

Почему?

Потому что файл в домашнем каталоге обычно имеет тип вроде user_home_t, а веб-сервер работает в домене httpd_t. Политика SELinux обычно не разрешает httpd_t читать user_home_t.

Как это выглядит снаружи

• в браузере ошибка 403 Forbidden;
• в логах может быть Permission denied;
• обычный chmod 644 не помогает.

Правильное решение

Назначить правильный SELinux-контекст, например для веб-контента.

Примеры команд:

sudo chcon -R -t httpd_sys_content_t /home/max/site

Но chcon — временное решение: после relabel или восстановления меток оно может пропасть.

Более правильный путь:

sudo semanage fcontext -a -t httpd_sys_content_t '/home/max/site(/.*)?'
sudo restorecon -Rv /home/max/site

Смысл:

1. добавили правило постоянного назначения контекста;
2. применили его через restorecon.

Если веб-серверу нужно писать в каталог, тип обычно должен быть другим, например httpd_sys_rw_content_t.

22. Booleans в SELinux

Кроме контекстов, в SELinux есть booleans — переключатели политики.

Они включают или выключают некоторые допустимые сценарии.

Посмотреть все:

getsebool -a

Посмотреть подходящие по теме, например для httpd:

getsebool -a | grep httpd

Включить постоянно:

sudo setsebool -P httpd_can_network_connect on

Пример

Если веб-приложение должно ходить в сеть к внешнему API, одного правильного контекста может быть мало. Иногда нужен boolean вроде httpd_can_network_connect.

Важная мысль

SELinux-проблема не всегда решается только relabel’ом файлов. Иногда контексты верные, но нужный сценарий выключен boolean’ом.

24. Частые ошибки администрирования

Ошибка 1: лечить всё через chmod 777

Это почти никогда не правильное решение.
Если мешает SELinux, 777 не поможет.
Если проблема в владельце или группе, 777 создаёт лишнюю дыру в безопасности.

Ошибка 2: отключить SELinux вместо диагностики

Да, после этого «может заработать». Но одновременно ты убираешь важный слой защиты.

Ошибка 3: использовать только chcon

После relabel, восстановления контекстов или некоторых административных действий изменения могут исчезнуть.
Постоянное решение — semanage fcontext + restorecon.

Ошибка 4: забывать про права каталогов по пути

Файл может иметь 644, но если на одном из каталогов нет нужного x, доступа не будет.

Ошибка 5: не учитывать ACL

Иногда ls -l выглядит нормально, но доступ определяется ещё и ACL.
Признак — символ + в правах.

Ошибка 6: путать права на файл и права на каталог

Особенно при удалении, переименовании и создании файлов.

26. Как быстро разбираться с Permission denied

Полезный порядок проверки:

Шаг 1. Кто запускает процесс?

id
ps -ef | grep process_name
ps -eZ | grep process_name

Шаг 2. Какие права у файла?

ls -l file
stat file

Шаг 3. Какие права у каталогов по пути?

Проверять нужно весь путь, а не только конечный файл.

Шаг 4. Есть ли ACL?

getfacl file

Шаг 5. Включён ли SELinux?

getenforce
ls -Z file
ps -eZ | grep process_name

Шаг 6. Смотреть audit-логи

Если проблема именно в SELinux, логи обычно дают самый точный ответ.

28. Главное, что стоит запомнить

1. Обычные права Linux — это базовый уровень доступа.
2. Для каталогов r, w, x работают не так, как для файлов.
3. Удаление файла определяется в первую очередь правами на каталог.
4. setgid на каталоге очень полезен для групповой работы.
5. ACL нужны, когда модели owner/group/others недостаточно.
6. SELinux — отдельный слой контроля, который может запретить доступ даже при «правильных» chmod.
7. Если на системе включён SELinux, при ошибке Permission denied всегда проверяй не только UNIX-права, но и:
   • контексты;
   • booleans;
   • audit-логи.
8. chmod 777 и отключение SELinux — почти всегда плохое лечение.

30. Небольшой мысленный тест

Вопрос 1

Файл имеет права 644. Может ли другой пользователь его удалить?

Ответ: да, если у него есть нужные права (w+x) на каталог, где лежит файл.

Вопрос 2

Каталог имеет r-- без x. Можно ли в него «зайти»?

Ответ: нет. Можно увидеть список имён, но traversal обычно не будет работать.

Вопрос 3

Файл имеет 777, но сервис всё равно не может его читать. Почему?

Ответ: возможны причины:
/

• нет x на одном из каталогов по пути;
• мешает SELinux;
• есть ACL-ограничение;
• проблема не в чтении файла, а в другом доступе.

Вопрос 4

Почему chcon иногда «слетает»?

Ответ: потому что это не постоянное правило политики. Для постоянной настройки нужен semanage fcontext, затем restorecon.

---

31. Итог в одной фразе

Обычные права Linux отвечают на вопрос «кому владелец разрешил доступ», а SELinux — «разрешает ли это политика безопасности вообще». Для реальной диагностики нужно учитывать оба уровня одновременно.