Примеры ACL

Введение: ACL в сравнении с разрешениями

До реализации списков контроля доступа (ACL) модель разрешения HDFS была эквивалентна традиционным UNIX-разрешениям. В этой модели разрешения для каждого файла или каталога управляются набором из трех различных пользовательских классов: “Владелец”, “Группа” и “Другие”. Для каждого пользовательского класса существует три разрешения: чтение, запись и выполнение. Таким образом, для любого объекта файловой системы его разрешения могут быть закодированы в 3*3=9 бит. Когда пользователь пытается получить доступ к объекту файловой системы, HDFS применяет разрешения в соответствии с конкретным классом пользователя, применимым к нему. Если пользователь является владельцем, HDFS проверяет разрешения класса “Владелец”. Если пользователь не является владельцем, но является членом группы объектов файловой системы, HDFS проверяет разрешения класса “Группа”. В противном случае HDFS проверяет разрешения класса “Другие”.

Эта модель может в достаточной степени удовлетворять большому количеству требований безопасности. Например, рассмотрим отдел продаж, который хотел бы, чтобы один пользователь – Брюс, менеджер отдела, – контролировал все изменения данных продаж. Другим сотрудникам отдела продаж необходимо просмотреть данные, но не следует изменять их. Все остальные компании (за пределами отдела продаж) не должны иметь возможность просматривать данные. Это требование может быть реализовано путем запуска chmod 640 в файле со следующим результатом:

-rw-r-----1 brucesales22K Nov 18 10:55 sales-data

Только Брюс может изменить файл, только члены группы продаж могут прочитать файл, и никто другой не может получить доступ к файлу каким-либо образом.

Предположим, что возникают новые требования. Отдел продаж вырос, и Брюс не может контролировать все изменения в файле. Новое требование состоит в том, что Брюсу, Диане и Кларку разрешено вносить изменения. К сожалению, для реализации этого требования не существует возможности для разрешений, потому что может быть только один владелец и одна группа, и группа уже используется для реализации требования только для чтения для команды продаж. Типичным обходным решением является установка владельца файла на мнимую учетную запись пользователя, такую как salesmgr, и разрешение Брюсу, Диане и Кларку использовать учетную запись salesmgr с помощью sudo или аналогичных механизмов. Недостатком этого обходного пути является то, что он создает сложность для конечных пользователей, требуя от них использовать разные учетные записи для разных действий.

Предположим теперь, что помимо сотрудников по продажам все руководители компании должны иметь возможность читать данные о продажах. Это еще одно требование, которое не может быть выражено с помощью разрешенных битов, поскольку существует только одна группа, и она уже используется в продажах. Типичным обходным решением является установка группы файлов в новую мнимую группу, такую как salesandexecs, и добавление всех пользователей sales и всех пользователей execs к этой группе. Недостатком этого обходного пути является то, что он требует от администраторов создание и управление дополнительными пользователями и группами.

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

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

Пример 1: Предоставление доступа к другой именованной группе

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

  • Установить ACL:
> hdfs dfs -setfacl -m group:execs:r-- /sales-data
  • Запустить getfacl, чтобы проверить результаты:
> hdfs dfs -getfacl /sales-data
# file: /sales-data
# owner: bruce
# group: sales
user::rw-
group::r--
group:execs:r--
mask::r--
other::---
  • Если запустить команду ls, можно увидеть, что перечисленные разрешения были добавлены с символом “+” для обозначения наличия ACL. Символ “+” добавляется к разрешениям любого файла или каталога с ACL.
> hdfs dfs -ls /sales-data
Found 1 items
-rw-r-----+  3 bruce sales          0 2014-03-04 16:31 /sales-data

Новая запись ACL добавляется к существующим разрешениям, определенным в разрешенных битах. Как владелец файла, Брюс имеет полный контроль. Члены группы sales или execs имеют доступ на чтение. У остальных нет доступа.

Пример 2: Использование ACL по умолчанию для автоматического применения к дочерним файлам и каталогам

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

Предположим, есть каталог “monthly-sales-data”, который далее подразделяется на отдельные каталоги для каждого месяца. Установим ACL по умолчанию, чтобы гарантировать, что члены группы execs автоматически получают доступ к новым подкаталогам по мере их создания каждый месяц.

  • Установить ACL по умолчанию в родительский каталог:
> hdfs dfs -setfacl -m default:group:execs:r-x /monthly-sales-data
  • Создать подкаталоги:

> hdfs dfs -mkdir /monthly-sales-data/JAN

> hdfs dfs -mkdir /monthly-sales-data/FEB

  • Убедиться, что HDFS автоматически применил ACL по умолчанию в подкаталоги:
> hdfs dfs -getfacl -R /monthly-sales-data
# file: /monthly-sales-data
# owner: bruce
# group: sales
user::rwx
group::r-x
other::---
default:user::rwx
default:group::r-x
default:group:execs:r-x
default:mask::r-x
default:other::---

# file: /monthly-sales-data/FEB
# owner: bruce
# group: sales
user::rwx
group::r-x
group:execs:r-x
mask::r-x
other::---
default:user::rwx
default:group::r-x
default:group:execs:r-x
default:mask::r-x
default:other::---

# file: /monthly-sales-data/JAN
# owner: bruce
# group: sales
user::rwx
group::r-x
group:execs:r-x
mask::r-x
other::---
default:user::rwx
default:group::r-x
default:group:execs:r-x
default:mask::r-x
default:other::---

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

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

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

  1. Добавить запись ACL для блокировки всего доступа пользователя Диана к “monthly-sales-data”:

    > hdfs dfs -setfacl -m user:diana:--- /monthly-sales-data

  2. Запустить getfacl для проверки результатов:

    > hdfs dfs -getfacl /monthly-sales-data
    # file: /monthly-sales-data
    # owner: bruce
    # group: sales
    user::rwx
    user:diana:---
    group::r-x
    mask::r-x
    other::---
    default:user::rwx
    default:group::r-x
    default:group:execs:r-x
    default:mask::r-x
    default:other::---
    

Новая запись ACL добавляется к существующим разрешениям, определенным в Permission Bits. Брюс имеет полный контроль как владельц файла. Члены группы sales или execs имеют доступ на чтение. У остальных нет доступа.

Важно помнить о порядке оценки записей ACL, когда пользователь пытается получить доступ к объекту файловой системы:

  • Если пользователь является владельцем файла, применяются разрешения “Владелец”;
  • Если у пользователя есть запись ACL-пользователя, применяются соответствующие права;
  • Если пользователь является членом группы файлов или любой именованной группы в ACL, то для всех соответствующих записей принудительно объединяются разрешения (пользователь может быть членом нескольких групп);
  • Если ничто из вышеуказанного не применимо, назначаются разрешенные биты класса “Другие”.

В данном примере запись ACL-пользователя достигла установленной цели, поскольку пользователь не является владельцем файла, а именованная пользовательская запись имеет приоритет над всеми другими записями.