ACL в Linux: практическое руководство по управлению доступом

К чему служат ACL и зачем их использовать

Access Control Lists (ACL) дополняют стандартную модель прав файловой системы в Linux/Unix. Кратко: ACL дают возможность назначать дополнительные наборы прав для отдельных пользователей и групп поверх базовой тройки «владелец — группа — остальные». Это удобно, когда один файл или папка должны быть доступны нескольким конкретным людям, не меняя группу владельца и не открывая доступ всем.

Определение в 1 строке: ACL — расширение прав доступа, позволяющее назначать права отдельным именованным пользователям и группам и задавать шаблоны прав для новых объектов в директории.

Важно: ACL работают вместе со стандартными правами (r/w/x), маской и umask — их поведение нужно понять, чтобы не получить неожиданные результаты.

Основные понятия и краткое напоминание о стандартных правах

• Пользователь (user) — владелец файла.
• Группа (group) — группа, назначенная файлу.
• Остальные (other) — все остальные пользователи.
• Права: r — чтение, w — запись, x — выполнение/вход в директорию.

Пример команды для просмотра стандартных прав:

ls -l mysupersecretfile.txt

Пояснения к выводу ls:

1. Права владельца
2. Права группы
3. Права остальных
4. Имя владельца
5. Имя группы владельца

По умолчанию у нового пользователя создаётся группа с тем же именем. Это часто вызывает путаницу при интерпретации вывода ls.

Когда стандартных прав недостаточно

Сценарии, когда стандартной модели не хватает:

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

В таких случаях подходят ACL.

Проверка поддержки ACL на файловой системе

Большинство современных дистрибутивов и популярных файловых систем (ext4, XFS, ZFS) поддерживают ACL. Но иногда опция монтирования ACL может быть отключена или пакет утилит не установлен.

Проверка для ext2/3/4 с помощью tune2fs (пример для /dev/sda1):

sudo tune2fs -l /dev/sda1 | grep "Default mount options"

Альтернативно можно посмотреть параметры монтирования для интересующей точки монтирования:

mount | grep " /path/to/mount "

Если файловая система не поддерживает ACL или смонтирована без этой опции, команды getfacl/setfacl всё равно могут присутствовать, но изменения не будут сохраняться.

Примечание: разные файловые системы и версии ядра по‑разному интерпретируют опцию “acl”. Если сомневаетесь, проверьте документацию вашей FS.

Команда getfacl — как смотреть текущие ACL

getfacl выводит ACL для файла или директории.

getfacl report.pdf

Вывод обычно содержит «минимальный ACL» — он повторяет стандартные права владельца, группы и остальных. Если есть расширенные записи, они будут перечислены ниже.

Пример расширенного вывода:

# file: report.pdf
# owner: peter
# group: accounting
user::rw-
user:michael:rw-
group::r--
mask::rw-
other::---

Здесь видно дополнительного пользователя michael с правом чтения и записи. После добавления расширенных записей команда ls -l покажет «+» в конце блока прав, сигнализируя о наличии ACL:

ls -l report.pdf
-rw-r-----+ 1 peter accounting 12345 Jun 12 10:00 report.pdf

Команда setfacl — как назначать ACL

setfacl изменяет ACL. Основные сценарии:

• Добавить/изменить запись: setfacl -m
• Удалить запись: setfacl -x
• Удалить все ACL: setfacl -b
• Добавить/изменить дефолтные записи для директории: setfacl -d -m
• Рекурсивно применить: setfacl -R

Пример: дать пользователю lumberg право чтения файла report.pdf:

sudo setfacl -m u:lumberg:r report.pdf

Разбор синтаксиса:

• -m — modify (изменить/добавить)
• u: — тип записи (user). Для группы — g:, для остальных — o:
• lumberg: — имя пользователя, затем двоеточие
• r — права (r, w, x или их комбинация)

После применения проверьте результат:

getfacl report.pdf

Примеры практических команд

• Добавить права чтения и выполнения для группы testers на директорию project:

sudo setfacl -m g:testers:rx project

• Добавить дефолтную ACL для директории shared, чтобы новые файлы наследовали права:

sudo setfacl -d -m g:team:rwX shared

• Удалить конкретного пользователя из ACL файла:

sudo setfacl -x u:lumberg report.pdf

• Удалить все расширенные ACL у файла:

sudo setfacl -b report.pdf

• Применить рекурсивно в директории tree:

sudo setfacl -R -m u:alice:rwX tree

Default ACLs и поведение наследования

Дефолтные ACL применяются только к директориям и определяют права, которые будут назначены новым файлам и подпапкам, создаваемым внутри директории. Когда создаётся новый файл, система комбинирует дефолтный ACL директории с текущей umask процесса, поэтому итоговые права могут отличаться от ожиданий.

Важно понять: дефолтный ACL не изменяет уже существующие файлы — он влияет только на объекты, созданные после установки дефолтных ACL.

Пример установки дефолтного права для пользователя lumberg:

sudo setfacl -d -m u:lumberg:rwX Accounting

Буква X (заглавная) означает: предоставить execute только если это директория или если уже применим execute к файлу (обычное поведение позволяет избегать лишних x для обычных файлов).

Маска ACL и как она влияет на эффективные права

Понятие mask — одно из самых частых источников путаницы. Маска ограничивает максимальный набор прав для всех записей именованных групп и именованных пользователей (но не для владельца и не для записи other).

Пример вывода getfacl с маской:

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

Если mask установлена как r–, то даже если пользователь michael в записи имеет rw-, фактические права будут ограничены r–.

Чтобы изменить mask используйте setfacl с записью для группы (например меняя маску):

sudo setfacl -m m:rw- file

Примечание: setfacl автоматически обновляет mask при добавлении записей, но иногда требуется явное изменение, если вы хотите расширить права для уже существующих ACL.

Частые ошибки и когда ACL не решит задачу

Когда ACL не подойдёт:

• Нужна централизованная авторизация по политике (разумнее смотреть в сторону LDAP/AD и POSIX‑соответствующих механизмов с PAM/SSSD).
• Вы хотите детализированную политику на уровне атрибутов файла (тут лучше использовать SELinux/AppArmor).
• На файловой системе нет поддержки ACL или ACL отключены в монтировании.

Распространённые ошибки при работе с ACL:

• Ожидание, что дефолтный ACL немедленно изменит уже существующие файлы.
• Игнорирование маски — права именованных пользователей кажутся назначенными, но mask их ограничивает.
• Применение рекурсивного setfacl без понимания последствий для большого дерева — можно случайно испортить права множества файлов.

Отладка и проверка: пошаговый чек‑лист

1. Убедитесь, что FS поддерживает ACL и смонтирован с опцией ACL, если требуется.
2. Посмотрите текущие ACL: getfacl path
3. Проверяйте ls -l для символа +, означающего наличие расширенных ACL.
4. Если права не работают как ожидалось, проверьте mask: getfacl path | grep mask
5. Если дефолтные ACL не срабатывают для новых файлов, проверьте umask процесса, создающего файлы.
6. Для массовых изменений сначала протестируйте на небольшой директории.

Практический сценарий: офисный пример «Accounting»

Задача: папка /srv/accounting должна позволять:

• Владелец: full control (rwX)
• Группа accounting: rwX
• Внешний пользователь lumberg: только чтение всех текущих и будущих файлов
• Все новые файлы внутри должны автоматически получать эти права

Решение (пошагово):

1. Убедиться, что директорией владеет нужный пользователь и группа:

sudo chown manager:accounting /srv/accounting

2. Установить базовые права директории:

sudo chmod 2770 /srv/accounting

Примечание: бит 2 (setgid) гарантирует, что новые файлы наследуют группу владельца директории.

3. Установить дефолтные ACL для чтения lumberg и rw для группы:

sudo setfacl -d -m u:lumberg:rX,g:accounting:rwX /srv/accounting

4. Установить текущие ACL для существующих файлов (рекурсивно):

sudo setfacl -R -m u:lumberg:rX,g:accounting:rwX /srv/accounting

5. Проверить:

getfacl /srv/accounting | sed -n '1,20p'
ls -ld /srv/accounting

Критерии приёмки:

• getfacl показывает запись user:lumberg с правом rX и дефолтную запись с таким же набором
• Новая тестовая запись, созданная другим пользователем, наследует заданные права

Альтернативы ACL и когда использовать их

• Группы Unix + управление членством: простая и надёжная модель, подходит если количество комбинаций прав небольшое.
• POSIX‑ACL (то, о чём мы говорим) — удобна для гибкости без смены инфраструктуры.
• SELinux/AppArmor — нужно для тонкой политики безопасности, но сложнее в настройке.
• NFSv4 ACL — если требуется совместимость с Windows-подходом или распределённой файловой системой.

Выбор зависит от масштаба: для локальной гибкой настройки — ACL; для глобальной централизованной политики — IAM/LDAP + дополнительные механизмы.

Безопасность и соблюдение конфиденциальности

• ACL дают удобство, но увеличивают сложность аудита. Включите регулярные проверки прав и храните конфигурацию (скрипты setfacl) в системе контроля версий.
• Для конфиденциальных данных комбинируйте ACL с журналированием доступа и, при необходимости, шифрованием на уровне файловой системы.
• В контексте GDPR/локальных законов: убедитесь, что права доступа отражают принцип минимизации доступа и что есть журналы доступа для аудита.

Примеры команд для восстановления и отката

• Снять все расширенные ACL у дерева (внимание — действие необратимо, если нет резервной копии):

sudo setfacl -R -b /srv/accounting

• Снять только дефолтные ACL у директории:

sudo setfacl -k /srv/accounting

• Экспорт текущих ACL и сохранение в файл (для бэкапа перед массовыми изменениями):

getfacl -R /srv/accounting > /root/accounting-acls.backup

• Восстановление из бэкапа:

setfacl --restore=/root/accounting-acls.backup

Роль‑ориентированные чек‑листы

Администратор:

• Проверить поддержку ACL и опции монтирования
• Сделать бэкап существующих ACL: getfacl -R
• Протестировать setfacl на тестовой директории
• Настроить дефолтные ACL для директорий общего доступа
• Настроить мониторинг и журналы для доступа к критичным данным

Пользователь (получатель прав):

• Проверить свои права: ls -l и getfacl
• При жалобах на доступ — приложить вывод getfacl и ls -l для диагностики
• Не пытаться вручную менять владельца/группу без согласования с администратором

Набор тестов и критерии приёмки

Тестовые случаи:

1. Добавление пользователя lumberg в ACL файла — он может читать, но не редактировать.
2. Добавление дефолтного ACL в директорию — новый файл наследует права.
3. Изменение mask — права именованного пользователя действительно ограничены.
4. Удаление ACL через setfacl -b — ls больше не показывает + и getfacl не показывает расширенных записей.

Критерии приёмки:

• Все тесты выполняются локально и подтверждаются командами getfacl/ls.
• Для рекурсивных изменений проведён контрольный тест на случайных файлах, чтобы не нарушить доступ.

Решение: стоит ли вводить ACL у вас

Mermaid диаграмма принятия решения:

flowchart TD
  A[Нужна гибкая настройка доступа?] -->|Да| B{Доступ по конкретным
пользователям без создания новых групп}
  B -->|Да| C[Использовать ACL]
  B -->|Нет| D[Оставить группы POSIX]
  A -->|Нет| D
  C --> E{Есть поддержка FS и
административная практика}
  E -->|Да| F[Внедрять ACL постепенно]
  E -->|Нет| G[Настроить FS/монтирование или рассмотреть альтернативы]

Краткий словарь терминов

• ACL — расширенный список контроля доступа
• mask — ограничение максимального набора прав для именованных записей
• default ACL — ACL, применяемая к новым объектам внутри директории
• umask — маска, влияющая на права создаваемых файлов

Итог и рекомендации

Access Control Lists — мощный инструмент для гибкого распределения прав доступа на Unix/Linux. Они удобны, когда стандартная модель пользователь/группа/прочие оказывается недостаточной. При внедрении:

• Проверяйте поддержку файловой системы и опции монтирования.
• Тестируйте на образцах перед массовыми изменениями.
• Контролируйте маску и взаимодействие с umask.
• Храните экспорт ACL в резерве для восстановления.

Конечное резюме

ACL предоставляют тонкий и локально управляемый механизм контроля доступа, сокращая потребность в создании множества групп и делая наследование прав предсказуемым. Подходите к их использованию осознанно: документируйте изменения, тестируйте и сохраняйте резервные копии текущих ACL перед массовыми операциями.