Примеры ACL

ACL & Permission Bits

До реализации списков контроля доступа – ACL, модель разрешения HDFS была эквивалентна традиционным UNIX-разрешениям. В этой модели разрешения для каждого файла или каталога управляются набором из трех пользовательских классов: “owner”, “group” и “others”. Для каждого пользовательского класса существует три разрешения: чтение, запись и выполнение. Когда пользователь пытается получить доступ к объекту файловой системы, HDFS применяет разрешения в соответствии с конкретным классом пользователя. Если пользователь является владельцем, HDFS проверяет разрешения класса “owner”. Если пользователь не является владельцем, но является членом группы объектов файловой системы, HDFS проверяет разрешения класса “group”. В противном случае HDFS проверяет разрешения класса “others”.

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

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

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

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

Предположим далее, что помимо сотрудников по продажам все руководители компании должны иметь возможность читать данные о продажах. Это еще одно требование, которое не может быть выражено с помощью Permission Bits, поскольку может быть только одна группа, и она уже используется. Типичным обходным решением является установка группы файлов в новую мнимую группу, например, 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 добавляется к существующим разрешениям, определенным в Permission Bits. Как владелец файла, Брюс имеет полный контроль. Члены группы sales и execs имеют доступ на чтение. У других пользователей доступа нет.

Пример 2. ACL по умолчанию

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

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

  • Установить default 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 автоматически применил default 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::---

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

Пример 3. Блокировка доступа

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

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

    > hdfs dfs -setfacl -m user:diana:--- /monthly-sales-data
    
  • Запустить 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, когда пользователь пытается получить доступ к объекту файловой системы:

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

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