Классические права Unix описывают доступ всего тремя категориями: владелец, группа, остальные. Этого хватает, пока политика простая. Но как только один файл должен быть полностью доступен двум разным группам, а третьему пользователю - только на чтение, схема rwx упирается в потолок: групповое поле одно, и больше его не растянуть. В этом уроке разбираем POSIX ACL - механизм тонких прав на уровне отдельных пользователей и групп, а также расширенные атрибуты файлов (chattr/lsattr), которые меняют поведение файла независимо от того, кто им владеет.

Как это работает
ACL (Access Control List) - это список записей вида субъект:права, который файловая система хранит в расширенном атрибуте system.posix_acl_access. Каждая запись задаёт права для конкретного именованного пользователя (user:alice:rw-), именованной группы (group:devops:r--) или для базовых классов. Базовые записи owner, group, other совпадают с обычными rwx и синхронизированы с ними: меняя ACL владельца, вы меняете и вывод ls -l.
Ключевой и самый коварный элемент - маска (mask). Это верхняя граница эффективных прав для всех именованных пользователей и для группы-владельца. Реальные права = записанные в ACL И (логическое AND) маска. Если в ACL у пользователя стоит rw-, а маска r--, то фактически он получит только чтение. Маска нужна, чтобы старые программы, знающие лишь rwx, могли через chmod g+w грубо отрегулировать все ACL-права разом, не зная о существовании списка.
Дискреционный (discretionary) контроль означает, что решение о доступе принимает владелец объекта по своему усмотрению - в отличие от мандатного (SELinux, AppArmor), где политику задаёт система и владелец её не отменит. ACL - это по-прежнему DAC, просто более гранулярный.
Отдельная история - дефолтные (default) ACL на каталогах. Они не управляют доступом к самому каталогу, а служат шаблоном: каждый новый файл или подкаталог внутри наследует этот набор записей как свой стартовый ACL. Это решает классическую боль общих папок, где у новых файлов постоянно слетают групповые права.
Расширенные атрибуты chattr - это уже не про то, кто имеет доступ, а про то, что вообще можно делать с файлом. Они хранятся в inode и действуют поверх любых прав, включая root. Самые важные: i (immutable) - файл нельзя менять, удалять, переименовывать и создавать на него ссылки даже от root; a (append-only) - в файл можно только дописывать, что незаменимо для логов. Эти флаги может ставить и снимать только root (точнее, процесс с capability CAP_LINUX_IMMUTABLE).
Команды и примеры
Установка инструментов. ACL обычно уже встроены в ядро и util-linux, а вот команды могут лежать в отдельных пакетах:
Код: Выделить всё
# Debian 13 / Ubuntu 24.04
apt install acl attr
# RHEL 10 / Fedora 41+
dnf install acl attr
Код: Выделить всё
tune2fs -l /dev/sda2 | grep "Default mount options" # ext4
mount | grep " / " # активные опции
Код: Выделить всё
getfacl report.txt
# Дать пользователю alice чтение и запись
setfacl -m u:alice:rw report.txt
# Дать группе devops только чтение
setfacl -m g:devops:r report.txt
# Несколько правил за один вызов
setfacl -m u:alice:rw,g:devops:r,o::- report.txt
# Снять конкретную запись
setfacl -x u:alice report.txt
# Снести все расширенные ACL, оставить базовые rwx
setfacl -b report.txt
Код: Выделить всё
setfacl -m m::rx report.txt # потолок прав - чтение и выполнение
getfacl report.txt
# user:alice:rwx
# effective:r-x <- маска срезала запись
Дефолтные ACL на каталоге. Префикс d: или ключ -d:
Код: Выделить всё
mkdir /srv/shared
setfacl -d -m g:devops:rwx /srv/shared
setfacl -m g:devops:rwx /srv/shared # права на сам каталог тоже
# Рекурсивно навести порядок в существующем дереве
setfacl -R -m g:devops:rwx /srv/shared
setfacl -R -d -m g:devops:rwx /srv/shared
Код: Выделить всё
getfacl -R /srv/shared > acl.bak
setfacl --restore=acl.bak
cp -a src dst # -a сохраняет ACL и атрибуты, в отличие от cp -p
rsync -aA ... # ключ -A для копирования ACL
Код: Выделить всё
chattr +i /etc/resolv.conf # заморозить - не тронет даже root
lsattr /etc/resolv.conf
# ----i---------e------- /etc/resolv.conf
chattr -i /etc/resolv.conf # разморозить перед правкой
chattr +a /var/log/audit/audit.log # только дозапись
- Маска тихо срезает права. Пользователь по getfacl видит rwx, но реально работает r-x из-за маски. Всегда читайте строку effective, а не саму запись.
- chmod g+w на файле с ACL меняет не группу-владельца, а МАСКУ. Это сбивает с толку: кажется, что трогаешь группу, а на деле сдвигаешь потолок для всех именованных записей.
- Дефолтные ACL применяются только к НОВЫМ файлам. Уже лежащие в каталоге объекты не меняются - их нужно проходить отдельно через setfacl -R.
- cp -p и mv через границу файловой системы могут потерять ACL. Используйте cp -a или rsync -aA, а перед миграцией делайте getfacl -R в файл.
- Флаг +i ломает обновления и резервное копирование. Файл с immutable нельзя перезаписать пакетным менеджером, и забытый флаг превращается в загадочную ошибку Operation not permitted даже у root.
- chattr работает не на всех ФС одинаково. На ext4/XFS - да, а на сетевых и многих временных ФС флаги игнорируются или не поддерживаются.
- ACL не переживают tar без ключа --acls и архивацию в форматы, которые их не хранят.
- Создайте каталог /srv/team, двух пользователей и группу devops, добавьте пользователей в группу.
- Поставьте на каталог дефолтный ACL: group:devops:rwx. Создайте внутри файл от одного пользователя и проверьте getfacl - запись devops должна унаследоваться.
- Третьему пользователю (не в группе) дайте на конкретный файл только чтение через setfacl -m u:bob:r и убедитесь, что писать он не может.
- Выставьте маску m::r-- и посмотрите, как в getfacl у записи devops появилась строка effective:r-- - объясните, почему запись на запись перестала работать.
- Сделайте бэкап через getfacl -R, удалите ACL ключом -b, восстановите через --restore и сверьте результат.
- Поставьте на тестовый файл +i, попробуйте удалить его от root, снимите флаг и удалите.
- Как вычисляются эффективные права именованного пользователя при наличии маски ACL и почему запись может оказаться шире фактических прав?
- Что именно меняет команда chmod g+w на файле, у которого есть расширенные ACL, и почему это часто приводит к ошибкам администрирования?
- Чем дефолтный ACL на каталоге отличается от обычного и на какие объекты он влияет?
- Какими ключами setfacl задать рекурсивно и обычный, и дефолтный ACL для существующего дерева каталогов?
- Чем флаг immutable отличается от снятия всех прав записи и почему его не может обойти root без изменения атрибута?
- Какие инструменты копирования и архивирования сохраняют ACL, а какие их теряют?