Настройка ACL в Linux

В прошлой статье мы разбирали, как устроены права доступа к файлам и каталогам в Linux, для чего нужны команды chmod и chown и как управлять разрешениями на чтение, запись и выполнение. И в большинстве случаев стандартной модели, когда у каждого файла есть владелец, группа и набор прав для остальных пользователей, вполне достаточно.

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

Для подобных ситуаций в Linux предусмотрены ACL (Access Control Lists), или попросту - списки контроля доступа. Они позволяют назначать индивидуальные разрешения пользователям и группам, сохраняя, в то-же время, существующих владельцев файлов и каталогов.

В этой статье мы с вами разберём, как настроить ACL и организовать наследование прав для новых файлов, а также рассмотрим, каким способом можно проверить, какие именно разрешения пользователь получил на самом деле.

 

 

 

 

Что такое ACL и чем они отличаются от chmod

Стандартные права на файлы и директории в Linux используют обозначения r (чтение), w (запись) и x (выполнение). Они назначаются владельцу файла, его группе и остальным пользователям.

Например если мы выполним следующую команду, указав какой либо каталог:

ls -ld /var/www/project

, то увидим приблизительно такой результат:

drwxr-x--- 2 www-data www-data 4096 Oct 20 12:00 /var/www/project

На этом примере мы видим, что владельцем директории является системный пользователь www-data. Он имеет полный доступ к директории, его группа может читать содержимое каталога, а остальные пользователи доступа лишены вовсе.

 

Теперь допустим, что разработчику с логином developer нужно дать доступ к редактированию файлов этого проекта. Конечно, мы можем включить его в группу www-data, но тогда он получит групповые права и на другие объекты, где эта группа используется.

А вот ACL позволяют выдать разрешения непосредственно пользователю developer и непосредственно на целевую директорию или файл.

Ниже мы собрали наглядную таблицу, в которой видно отличия chmod/chown от ACL инструмента.

Возможность	chmod/chown	ACL
Права владельца и основной группы	Да	Да
Индивидуальные права другим пользователям	Нет	Да
Права дополнительным группам	Нет	Да
Наследование разрешений	Нет	Да
Ограничение прав через маску	Нет	Да

Получается, что ACL дополняют стандартные разрешения Linux и оба этих механизма работают совместно. Поэтому изменение прав через chmod может повлиять на ACL к чему нужно быть готовым и постоянно держать это в голове.

 

 

 

 

Установка ACL в Linux

В современных файловых системах ext4 и XFS, на которых работает большинство серверов и рабочих станций, поддержка POSIX ACL обычно включена по умолчанию. Для управления правами нужны утилиты setfacl и getfacl.

В Debian и Ubuntu для их установки необходимо выполнить команды:

sudo apt update
sudo apt install acl

 

В Rocky Linux и AlmaLinux:

sudo dnf install acl

 

Чтобы проверить наличие утилиты в вашей системе выполните команду:

getfacl --version

Если данная команда работает и вернёт результат, значит инструменты установлены. Однако поддержку ACL самой файловой системой лучше проверить отдельно, особенно если файлы находятся на сетевом хранилище.

 

 

 

 

Как посмотреть и изменить права ACL

Давайте с вами создадим каталог и назначим ему ограниченный доступ:

sudo mkdir -p /srv/shared
sudo chmod 750 /srv/shared

 

Теперь посмотрим текущие разрешения на этот каталог с помощью установленной нами выше утилиты:

getfacl /srv/shared

Пример вывода:

# file: srv/shared
# owner: root
# group: root
user::rwx
group::r-x
other::---

 

Здесь мы видим обычные Linux права и никаких дополнительных записей здесь пока нет.

 

Назначение прав пользователю

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

sudo setfacl -m u:developer:rwx /srv/shared

В данной команде параметр -m изменяет ACL, u:developer указывает пользователя, а rwx задаёт разрешения.

 

После этого проверим, что поменялось:

getfacl /srv/shared
user::rwx
user:developer:rwx
group::r-x
mask::rwx
other::---

Мы видим, что теперь пользователь с логином developer может просматривать содержимое каталога и создавать в нём файлы. При этом заметим, что права на сам каталог не дают автоматического доступа к редактированию всех файлов внутри него.

 

Давайте проверим возможность создание файла для нашего пользователя, выполнив от его имени команду:

sudo -u developer touch /srv/shared/test.txt

И если ошибок нет, то это значит, что разрешения работают.

 

Назначение прав группе

Как мы помним, у нас есть группа backup, которой нужен доступ только на чтение, чтобы делать резервные копии. Для того, чтобы выдать эти права, используем аналогичную команду, но указываем не пользователя u:developer , а группу g:backup :

sudo setfacl -m g:backup:rx /srv/shared

 

Если же это разрешение нужно применить ко всему существующему дереву, тогда используем параметр -R :

sudo setfacl -R -m g:backup:rX /srv/shared

 

Заглавная X в команде setfacl работает немного иначе, чем строчная x. Она добавляет право выполнения всем каталогам, а обычным файлам - только в том случае, если у них уже есть разрешение на выполнение хотя бы для одной категории пользователей.

Для каталогов право x необходимо, чтобы пользователь мог переходить в них и обращаться к файлам внутри. А вот обычным файлам, например .txt, .html или .jpg, такое разрешение чаще всего не требуется.

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

 

 

 

 

Наследование прав через Default ACL

Обычные ACL действуют на конкретные файлы и каталоги. Но вот если, например, завтра в каталоге /srv/shared появится новый файл, то пользователь developer может не получить к нему доступ.

Для решения этой проблемы существуют так называемые Default ACL - наследуемые разрешения. Они выставляются уже знакомой нам командой, но с использованием параметра я -d:

sudo setfacl -d -m u:developer:rwx /srv/shared

Теперь новые файлы, созданные внутри нашего каталога, а также его подкаталоги будут наследовать запись, созданную для пользователя developer.

 

Проверить настройки наследования можно командой:

getfacl -d /srv/shared

Пример:

default:user::rwx
default:user:developer:rwx
default:group::r-x
default:mask::rwx
default:other::---

 

Однако у наследования ACL есть несколько особенностей. Допустим, мы настроили для пользователя developer права rwx по умолчанию:

sudo setfacl -d -m u:developer:rwx /srv/shared

Очевидно, что теперь все новые файлы и подкаталоги внутри /srv/shared будут наследовать эту запись. Но фактические разрешения зависят от типа создаваемого объекта.

Например, когда программа создаёт обычный текстовый файл, она чаще всего запрашивает права 0666 - чтение и запись для всех категорий пользователей, без разрешения на выполнение. Поэтому даже при наличии rwx в Default ACL пользователь developer получит для такого файла только rw-.

С каталогами ситуация иная. Обычно они создаются с запрошенными правами 0777, которые включают и выполнение, поэтому новый подкаталог может унаследовать полный набор разрешений rwx.

 

Что такое umask и как она связана с ACL

В Linux есть ещё один механизм управления разрешениями - umask (user file-creation mode mask). Это маска, которая ограничивает права доступа при создании новых файлов и каталогов.

По умолчанию программы обычно запрашивают права 0666 для файлов и 0777 для каталогов. Но предоставлять все эти разрешения каждому пользователю небезопасно, поэтому Linux применяет umask, которая убирает определённые биты доступа.

Посмотреть текущую маску можно командой:

umask

Например, если результат 0022, то новые объекты обычно получат следующие права:

Объект	Запрошенные права	umask	Итоговые права
Файл	0666	0022	0644 (rw-r--r--)
Каталог	0777	0022	0755 (rwxr-xr-x)

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

 

Вы спросите, как это связано с Default ACL? А мы вам ответим.

Если у родительского каталога настроены Default ACL, Linux использует наследуемые правила и режим, запрошенный программой. Обычная umask при этом отдельно не применяется.

Поэтому файл, созданный в каталоге с Default ACL, может получить более широкие разрешения, чем привычные 0644. Всё зависит от настроенных правил наследования и режима создания.

И последний нюанс, о котором не стоит забывать. Default ACL действуют только на новые объекты. Уже существующие файлы сохраняют прежние разрешения, поэтому чтобы изменить их, вам потребуется обычная команда setfacl -m, при необходимости с параметром -R для рекурсивной настройки.

 

 

 

 

Маска ACL и эффективные разрешения

Выше мы разобрали umask, которая ограничивает права при создании новых файлов и каталогов. Но в ACL есть и собственная маска - mask, которая работает иначе.

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

Например, пользователю developer назначены права rwx, но изменить файл он почему-то не может. Проверим ACL:

user:developer:rwx       #effective:r-x
mask::r-x

Здесь запись user:developer:rwx разрешает чтение, запись и выполнение. Но маска mask::r-x запрещает запись, поэтому фактические (эффективные) права пользователя ограничены до r-x. Именно их показывает комментарий #effective.

 

Маска ACL распространяется на дополнительные записи пользователей, основную группу файла и дополнительные группы. На владельца файла (user::) и остальных пользователей (other::) она не действует.

 

Изменить маску можно командой:

sudo setfacl -m m::rwx /srv/shared

После этого маска разрешит все права rwx, но каждый пользователь по-прежнему будет ограничен разрешениями своей записи ACL.

Правда тут тоже есть нюанс. Расширение маски может одновременно увеличить фактические права нескольких пользователей и групп. Поэтому перед изменением лучше посмотреть весь список через getfacl.

 

Ещё одно отличие от umask связано с командой chmod. Так, если у файла настроены расширенные ACL, то изменение групповых разрешений через chmod обычно меняет именно маску ACL. Например:

sudo chmod g-w /srv/shared

Эта команда уберёт право записи из маски ACL каталога, если у него есть расширенные записи. В результате пользователи, которым ранее была разрешена запись через ACL, могут потерять эту возможность.

 

Проверить итоговые разрешения можно командой:

getfacl /srv/shared

Итак, зафиксируем, что umask ограничивает права при создании объектов, а маска ACL (mask) ограничивает эффективные разрешения, предоставляемые записями ACL.

 

 

 

 

Удаление ACL и резервное копирование

Удалить разрешение конкретного пользователя можно командой:

sudo setfacl -x u:developer /srv/shared

 

Удалить дополнительные записи ACL доступа, соответственно:

sudo setfacl -b /srv/shared

 

Удалить все наследуемые правила Default ACL:

sudo setfacl -k /srv/shared

 

Вообще-то, перед любыми массовым изменением ACL мы можем застраховаться от ошибок, сохранив текущие ACL, например в обычный текстовый файл acl-backup.txt , с помощью команды:

sudo getfacl -R -p /srv/shared > acl-backup.txt

 

Восстановление из этого файла выполняется ещё проще:

sudo setfacl --restore=acl-backup.txt

 

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

 

 

 

 

Как сохранить ACL при переносе файлов

Увы, при копировании файлов дополнительные разрешения могут потеряться. Поэтому для переноса, например, через rsync используйте параметр -A:

sudo rsync -aA /var/www/project/ /backup/project/

В этом примере параметр -a сохраняет основные атрибуты файлов, а параметр -A - именно списки ACL.

 

Если же вам нужно сохранить расширенные атрибуты файловой системы, тогда добавьте параметр -X:

sudo rsync -aAX /var/www/project/ /backup/project/

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

 

 

 

 

Почему ACL могут не работать

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

Давайте разберём наиболее распространённые проблемы, с которыми можно столкнуться при настройке ACL, и способы их диагностики, но только в наглядном, табличном виде:

Проблема	Возможная причина	Проверка
Permission denied	Недостаточные эффективные права	getfacl
Нет доступа к каталогу	Отсутствует x на пути	namei -l
Operation not supported	Нет поддержки ACL	findmnt -T /path
Права ограничены	Маска ACL	getfacl
Новые файлы без нужных прав	Ошибка в Default ACL	getfacl -d
ACL исчезли после переноса	Атрибуты не сохранились	Параметры копирования

 

Отдельно проверьте SELinux или AppArmor, если они используются на вашем сервере, так как эти механизмы могут запрещать доступ даже при корректных ACL.

Есть и особенность перемещения файлов внутри одной файловой системы. В таком случае файл обычно сохраняет прежние ACL, а наследуемые разрешения каталога назначения при этом заново не применяются.

 

 

 

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

А вот если у всех пользователей одинаковые полномочия, тогда, конечно, проще использовать обычную Linux группу.

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

И главным, при работе с ACL остается постоянно проверять эффективные права, аккуратно настраивать наследование и сохранять ACL при переносе данных.