Что такое setfacl linux

Access Control Lists (Русский)

Списки управления доступом (Access Control Lists, ACL) — расширенный, более гибкий механизм прав доступа для файловых систем, разработанный как дополнение к стандартным правам доступа UNIX. ACL позволяет задавать права доступа к объектам на диске для пользователей и групп.

Contents

Установка

Пакет acl уже установлен, так как является зависимостью systemd.

Включение ACL

Для использования ACL файловая система должна быть смонтирована с опцией acl . Файл fstab позволяет настроить постоянное монтирование с данной опцией.

В некоторых файловых системах параметр монтирования acl включён по умолчанию. К таким файловым системам относятся Btrfs и Ext2/3/4. Следующая команда позволяет проверить раздел с файловой системой ext* на наличие параметра acl :

Убедитесь, что используемая по умолчанию опция не была переопределена. Об этом будет свидетельствовать параметр noacl в соответствующей строке файла /proc/mounts .

Задать параметры монтирования файловой системы по умолчанию можно командой tune2fs -o параметр раздел , например:

Это очень удобно при работе с внешними дисками, поскольку такой диск будет монтироваться с опцией acl и на других Linux-машинах. В противном случае придётся редактировать файл /etc/fstab на каждой системе.

Использование

Изменение ACL

Для изменения прав ACL используется команда setfacl.

Задать права пользователя (в качестве пользователь можно использовать имя пользователя или его ID):

Задать права группы (в качестве группа можно использовать имя группы или её ID):

Задать права для остальных:

Настроить наследование новыми файлами и каталогами записей ACL родительского каталога (не относится к файлам/каталогам, которые копируются в каталог):

Удалить определённую запись ACL:

Удалить записи по умолчанию:

Удалить все записи ACL:

The factual accuracy of this article or section is disputed.

Просмотр ACL

Вывести права доступа ACL:

Примеры

Установить все права доступа к файлу abc для пользователя johnny :

Измененить права для пользователя johnny :

Удалить все записи ACL:

Вывод команды ls

Символ + (плюс) после прав доступа Unix в выводе команды ls -l указывает на использование ACL:

Права на выполнение личных файлов

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

Будем считать что веб-сервер работает от пользователя http и получает доступ к домашнему каталогу /home/geoffrey пользователя geoffrey .

Санчала предоставим права на выполнение для пользователя http :

Поскольку пользователь http теперь имеет доступ к файлам в /home/geoffrey то безопаснее будет удалить доступ для остальных пользователей:

Проверим изменения с помощью getfacl :

Как видно из вывода, other больше не имеют никаких прав, но пользователь http всё ещё может обращаться к файлам.

Если необходимо будет выдать пользователю http права доступа на запись в определённые файлы/каталоги, выполните:

Источник

Что такое setfacl linux

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

Зачем оно нужно

Как известно «из коробки» нам доступен стандартный набор прав на файлы: «пользователь — группа — остальные» («user-group-others») плюс такие «бонусы» как SUID, SGID и Sticky биты. Подробнее об этом написано ТУТ (где . ). Возможности, предоставляемые стандартным набором прав, достаточно велики, чтобы потребовалось нечто большее, но бывают ситуации, когда нужно дать доступ отдельным пользователям (группам) на файлы, собственниками которых они не являются, либо, наоборот, сделать явный запрет не для всех.

Проверка на возможность работы с ACL

Вообще говоря, ACL должны поддерживаться файловой системой (раз) и сама файловая система должна быть смонтирована с поддержкой ACL.

Иначе изменять ACL правила будет невозможно, но имеющиеся все же применяться будут. Может быть, наоборот: изменять acl будет возможно, но применяться они не будут?

Монтировать нужно с параметром acl.

Проверим это командой:

Кроме того нам необходим нехитрый инструментарий, который в ALTLinux содержится в пакете acl:

Так мы получим две команды: setfacl и getfacl

Расширенные права

Если рассмотреть файл с точки зрения расширенных прав, то теперь мы оперируем следующим:

• владелец
• другие отдельные пользователи (поименно)
• группа владельца
• отдельные группы (тоже списком)
• остальные
• mask (важное дополнение)

И помимо этого, только для каталогов, есть те же самые «структурные единицы», права которых будут применяться по-умолчанию для всех объектов, создаваемых в этом каталогов.

На каждого пользователя/группы и остальных действуют права по принципу rwx, аналогично стандартным (для файла — читать, изменять, выполнять; для каталога — листинг, изменение, доступ к содержимому).

Однако, те права, которые назначены группе пользователя, другим группам, а также пользователям, отличных от владельца, ещё и обрабатываются параметром mask. Таким образом, эффективное значение прав доступа для указанных групп (нетронутыми остаются только сам владелец и «остальные») является логическое «И» начального значения и маски.

Ликбез по getfacl

Посмотреть полные права файла или каталога:

• Полезный параметр: показывать номера uid/gid, вместо имен: -n
• Если нужно показать права файлов в папке (обработать рекурсивно): -R
• Остальные опции — см. man getfacl

Ликбез по setfacl

Каталоги обрабатываются как файлы.

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

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

• Изменить ACL записи:

пользователя	setfacl -m u::rw	chmod u=rw
именованного пользователя	setfacl -m u:mister:rx
группы	setfacl -m g:mister:r	chmod g=r
именованной группы	setfacl -m g:mister:x
остальным	setfacl -m o:—	chmod o=
параметр mask	setfacl -m m:r-x

Преобразование прав. Параметр mask

Если раньше маски у файла не было (не путать с параметром umask — он здесь ни при чём), то как он назначается? Дело в том, что, когда файлу дают дополнительные права, то происходит «преобразование» исходных прав до полного комплекта ACL. Пример:

1. В выводе ls после списка прав появился знак «плюс», что указывает на неполноту информации — следует использовать getfacl для получения всей информации о правах.
2. getfacl дает две новые строчки: mask::r— и user:mister:rw- #effective:r— Результат применения маски на те права, что мы дали mister’у очевиден, но откуда взялась сама маска ? Ответ: при расширении стандартных прав до полных ACL маска становится такой же, как права группы до модификации. В нашем случае, r—.
3. Значение group также осталось неизменным, но это не обязательно, так как если файл создается в директории, на которую назначены права по-умолчанию, то применяться к файлу будут именно они. И еще одно правило: при работе с расширенными правами параметр umask силы не имеет, но mode действует: файлы (в отличие от директорий) создаются без права на исполнение.

Замечу, что параметр mask создается в том случае, когда задается хотя бы одна именованная запись (группа или пользователь). Соответственно, своя маска для прав файла и дефолтная — для директорий. Если же просто добавить неименованные default записи к стандартному файлу, mask тоже не создается. Воспользуемся этим:

Теперь мы видим:

1. Маска нигде не создается. И ограничений от нее нет. (Иначе group превратилась бы в mask и «испортила» права.)
2. Файлы создаются в «ACL-ной» директории обычные, а вот новые директории перенимают default права.
3. Файлам не дается право запуска (mode ограничение).

Если же мы добавим права конкретного пользователя к директории:

То тут же получим весь букет ограничений от маски для измененного файла/директории (но не вложенных !)

Отличие setfacl при (не)использовании опции -n

Теперь нужно покончить с маской, определив в чем особенность опции ‘-n’ команды setfacl. Видимо, маска кому-то уже «мешалась под ногами», поэтому при применении команды setfacl по-умолчанию (т.е. без опции -n) происходит расширение маски до «минимально допустимого набора прав, при котором не ограничиваются все остальные». То есть mask дополняется настолько, чтобы effective права совпадали с предписанными.

Как видим, теперь маска «расширилась» до предела (из-за того, что user:mister требует всех прав). К сожалению, только явное использование команды setfacl скрыто меняет маску. Если мы копируем/перемещаем обычный файл в директорию, у которой есть именованные дефолтные пользователи или группы, то файл обязан будет получить параметр mask и, внимание, получит его не от параметра default:mask директории, а от своего значения для группы ! Посмотрим на примере:

1. Параметр group::rwx взят из default:group: родительского каталога (в отличие от остальных, где, например, запрет на запуск появился).
2. Параметр mask взял значение из стандартного group и «задушил» права group и user:mister

Самым надежным способом избавиться от последствий маски считаю явное ее переопределение:

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

Вопросы на проверку

• Если файл уже имеет ACL записи, то применение команды chmod 0600 «умножит на ноль» права группы владельца или уже маски ? Ответ остается в силе, если маска еще не задается (неименованные ACL записи только) ? Проверить при разном изменении прав: 0777, a+x, g-r и т.п.

Ответ: Если ACL права уже есть, то применение команды chmod 0600 действует не на группу, а на маску, если она задана! В примере ниже это явно видно:

Причем применение синтаксиса chmod g+rw file1 также изменит именно маску !

Если маска еще не задана, то применение chmod меняет права группы, маска не появляется:

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

• Изменяет ли применение команд setfacl метку файлов mdate, другие (. )date ?

Ответ: при назначении прав через setfacl или при перемещении обычного файла в директорию с именными default ACL правами меняется только ctime (время последней смены атрибутов), getfacl — не меняет ничего. (Тесты выполнялись с применением утилиты stat.)

• Как разруливается конфликт прав, если после смены владельца/группы имеется ACL запись, которая совпадает по имени пользователя/группы и имеет другой уровень прав ? Не применяется ли предписанный ACL уровень прав на права нового владельца при chown ?

Ответ: права, предписанные в полях owner и group сохраняются при chown и являются неукоснительными для владельца (именные ACL-записи игнорируются, даже если есть совпадение). В примере ниже файл не дает себя запустить новому владельцу несмотря на ACL-запись, а основные права не изменились совсем:

Вывод: утилита chown понятия не имеет об ACL’ных правах, как и chmod.

• Операция chmod -R a+rwx сделает все каталоги доступными, а файлы запускаемыми. Как обрабатываются файлы, если к ним применить дефолтные ACL права явно или рекурсией ? Будут ли сообщения об ошибках ?

Применение дефолтных прав возможно двумя видами записей: или setfacl -R -d -nm u:user1:rwx или setfacl -R d:u:user1:rwx . Последний вариант не выдает ошибок даже если явно и без рекурсии применить его к файлу, а не каталогу. Разумеется, никакие атрибуты фактически не изменятся:

Другой вариант тоже молча выполняет изменение прав директорий, ни слова не говоря о файле. Файл же остается нетронутым. Вывод — применение «дефолтных» прав к файлу молча подавляется, даже не расширяя базовый набор его прав до ACL’ных.

Источник

Access Control List — списки контроля доступа

Содержание

Поддерживаемые версии Ubuntu
Все с ядром 2.4.21 (?) и выше, а также другие ОС

Вступление

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

Устоявшиеся истины:

Чтобы добавить пользователя в ту, или иную группу, достаточно отредактировать файл /etc/group:

Примечание прислал Лихоманенко Артем 2013/04/23 15:55

Видно, что в листинге выше в группу scanner входят пользователи hplip и allexserv. Чтобы добавить в эту группу еще пользователей, просто перечислите их символьные имена через запятую.

Синтаксис файла прост:

имя_группы:пароль:GID:список_пользователей

Итак, основная мысль статьи — это использование расширенных прав ACL . 2)

Включение ACL в системе

В тех разделах винчестера, в которых указан дополнительный параметр acl команды mount — grpquota,acl,suid — списки контроля будут поддерживаться в полном объеме. В моем случае поддержка ACL активирована на разделах /dev/sda5 и /dev/sda6.

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

Утилиты ACL

Существуют два типа ACL :

Но не все так грустно! Перевод статьи был написан в 2006 году (к сожалению до оригинала я так и не добрался). В другой же статье, более поздней, сказано:

Итак, рассмотрим синтаксис и параметры getfacl и setfacl.

Утилита getfacl

О getfacl сильно и говорить нечего. Она выводит листинг ACL прав для указанных объектов.

Теперь рассмотрим, что же отобразит команда getfacl:

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

Утилита setfacl

Теперь об утилите setfacl. Как уже говорилось выше, утилита setfacl предназначена для установки, модификации или удаления ACL .

Рассмотрим простой синтаксис setfacl:

setfacl

Часто используемые ключи:

Ключ	Описание
— Устанавливает новые указанные права ACL , удаляя все существующие. Необходимо, чтобы наравне с задаваемыми правилами ACL были также указаны стандартные права Unix, в противном случае будет давать ошибку;
— Модифицирует указанные ACL на объекте. Другие существующие ACL сохраняются.
— Удаляет указанные ACL права с объекта. Стандартные права Unix не изменяются.

Часто используемые опции:

Опция	Описание
-b	— Удаляет все ACL права с объекта, сохраняя основные права;
-k	— Удаляет с объекта ACL по умолчанию. Если таковых на объекте нет, предупреждение об этом выдаваться не будет;
-d	— Устанавливает ACL по умолчанию на объект.
–restore=file	— Восстанавливает ACL права на объекты из ранее созданного файла с правами. 5)
-R	— Рекурсивное назначение (удаление) прав, тобишь пройтись по всем подкаталогам.

Формирование списка правил:

Синтаксис	Описание	Пример использования
— Назначает ACL для доступа заданному пользователю. Здесь можно указать имя или UID пользователя. Это может быть любой пользователь, допустимый в данной системе.	Пример:

— назначает пользователю allexserv права на чтение и запись.

— Назначает ACL для доступа заданной группе. Здесь можно указать имя или GID группы. Это может быть любая группа, допустимая в данной системе. Пример:

— назначает группе children права на чтение.

— Назначает маску эффективных прав. 6) Пример:

— устанавливает фактические максимальные права на чтение и выполнение.

— Назначает ACL для доступа пользователям, не включённым в группу файла. Это пользователь «все остальные», как в стандартных правах Unix. Пример:

— убирает все права (отсутствие прав).

— Сами правила для пользователя или группы. Могут принимать значения ( r ), ( x ), ( w ), или сочетания друг с другом.

Примеры использования

Теперь давайте добавим к этому файлу еще пользователя allexserv:

Теоретически, в данном случае пользователь child не может удалить файл (про allexserv ничего не говорю, т.к. он входит в группу root у меня). Но проведя тест, пользователь child все-таки удалил файл, правда перед удалением система спросила:

В то же время попробовал отредактировать файл qwert под пользователем child и попытался записать изменения. Система в записи отказала. Здесь стоит отметить, что удаление файла регламентируется правами на каталог в коем расположен этот файл. Причина такого поведения именно в этом.

Теперь давайте удалим с файла qwert права ACL для пользователя allexserv:

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

Задача: создадим каталог Proverka и назначим ему владельца child и группу children (разумеется, пользователь и группа должны существовать в системе). Установим ACL права для пользователя allexserv и пользователя mysql. Установим ACL по умолчанию на каталог Proverka так, чтобы создаваемым объектам внутри него также назначались ACL .

Создаем каталог, устанавливаем права и владельца:

Видно, что появились строки начинающиеся с default. Это и есть права по умолчанию, которые будут принимать все создаваемые внутри объекты. Проверим, создав пустой файл myfile.txt и подкаталог MyKatalog в каталоге Proverka:

Удалить права по умолчанию можно: setfacl -k Proverka.

Если нужно также удалить права по умолчанию и в подкаталогах, то добавьте ключ -R (рекурсия): setfacl -R -k /media/Work/test/Proverka .

Здесь мы оперировали двумя пользователями. Но ничто не мешает вам оперировать также целыми группами пользователей.

Автоматические операции

Любой администратор стремится к оптимизации. Понятно, что назначить вручную 100 объектам одни и те же права — нудное занятие и нецелесообразное. Есть некоторые фишечки, которые могут облегчить подобные задачи.

Копирование ACL прав с одного объекта на другой.

В документации приведен следующий пример:

Справедлива будет также такая запись:

В этом случае права на file2 не заменяются как при использовании — -set, а добавляются к уже существующим правам ACL .

Копирование прав ACL каталога в права по умолчанию этого же каталога

В этом примере getfacl получает все права которые вы установили на каталог dir и устанавливает их на этот же каталог dir делая их правами по умолчанию. Очень удобно. Обратите внимание на ключ — -access у команды getfacl. При вызове getfacl без параметров, она отображает все права ACL , включая права по умолчанию. Здесь же, ключ — -access заставляет getfacl показать только права ACL на каталог, а права по умолчанию (если таковые имеются у каталога) — скрыть. Обратный ключ — это ключ -d:

можно было бы воспользоваться именно этой фишечкой, как то так:

Результат был бы тот же.

Вот и все, а вообще, не поленитесь почитать man getfacl, очень занимательно!

Операции над объектами c ACL

В заключении хочу еще раз обратить внимание на операции с обектами у которых установлены ACL , такие как копирование, перемещение, архивирование. Выше мы уже упоминали о них. Некоторые замечания:

Утилиту star нужно будет установить из репозиториев: apt-get install star

Вот некоторые часто используемые опции star:

Опция	Описание
-c	Создаёт файл архива
-n	Отключает извлечение файлов, используется в сочетании с -x для просмотра списка извлекаемых файлов.
-r	Заменяет файлы в архиве. Файлы записываются в конец архива, заменяя любые файлы с тем же путём и именем.
-t	Выводит содержимое файла архива.
-u	Обновляет файл архива. Файлы записываются в конец архива, если их ещё не было в архиве или если они новее, чем файлы с тем же именем в архиве. 7)
-x	Извлекает файлы из архива. Если используется с ключом -U и файл в архиве старее, чем соответствующий файл в файловой системе, такой файл не извлекается.
-help	Выводит наиболее важные параметры.
-xhelp	Выводит менее важные параметры.
-/	Оставляет ведущую косую черту в имени файла при извлечении файлов из архива. По умолчанию она убирается.
-acl	При создании архива или извлечении файлов, архивирует или восстанавливает все ACL , связанные с файлами или каталогами.

Пример для архивирования утилитой star с сжатием:

star -czv -Hexustar -acl -f /tmp/homedir.tgz /media/Profil/home

Пример для разархивирования в текущий каталог:

star -xv -Hexustar -acl -f homedir.tgz

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

© 2012 Ubuntu-ru — Русскоязычное сообщество Ubuntu Linux.
© 2012 Canonical Ltd. Ubuntu и Canonical являются зарегистрированными торговыми знаками Canonical Ltd.

Источник