POSIX ACL на HDFS

Списки ACL на HDFS реализуются с помощью модели ACL POSIX, которая работает так же, как и в файловой системе Linux:

Совместимость и применение

HDFS может связывать дополнительный список ACL с любым файлом или каталогом. Все операции HDFS, которые обеспечивают соблюдение разрешений, выраженных с помощью Permission Bits, также должны обеспечить любой ACL, который определен для файла или каталога. Так же как и любая существующая логика, которая обходит Permission Bits, обходит и ACL. Включая супер-пользователя HDFS и установку false в конфигурации dfs.permissions.

Доступ

HDFS поддерживает операции по настройке и получению ACL, связанного с файлом или каталогом. Эти операции доступны через несколько ориентированных на пользователя конечных точек. Эти конечные точки включают FsShell CLI, программную манипуляцию через классы FileSystem и FileContext, WebHDFS и NFS.

Обратная связь

К разрешениям любого файла или каталога с ACL добавляется символ + (вывод команды ls -l).

Обратная совместимость

Реализация ACL обратно совместима с существующими Permission Bits. Изменения, применяемые посредством разрешенных битов (то есть chmod), также отображаются как изменения в ACL. Аналогично, изменения, применяемые к записям ACL для базовых классов пользователей (“Owner”, “Group” и “Other”), отображаются в виде изменений в Permission Bits.

Другими словами, операции Permission Bits и ACL управляют совместно используемой моделью, и операции Permission Bits можно рассматривать как подмножество операций ACL.

Накладные расходы

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

Ограничения

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

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

Символические ссылки

У символических ссылок нет собственных списков ACL, поэтому они рассматривается как разрешения по умолчанию (777 в Permission Bits). Операции, которые изменяют список символической ссылки, вместо этого изменяют саму символическую ссылку.

Снапшоты

При создании снапшота все списки ACL блокируются. Изменения в ACL в момент создания снапшота не фиксируются.

Инструментарий

Инструментарий для Permission Bits не подходит для ACL. Списки включаются командой оболочки cp -p и distcp -p.

Доступ нескольким пользователям

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

ACLs on HDFS supports the following use cases:

Доступ нескольким группам

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

group:sales:rw-
group:execs:rw-

Hive Partitioned Tables

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

user
`-- hive
    `-- warehouse
        `-- sales
            |-- country=CN
            |-- country=GB
            `-- country=US

Группа salesadmin – группа для всех файлов. Члены группы имеют доступ на чтение и запись ко всем файлам. Отдельные группы, зависящие от конкретной страны, могут запускать запросы на использование, которые только считывают данные для конкретной страны, например, sales_CN, sales_GB и sales_US. У этих групп нет доступа на запись.

Такой вариант использования можно решить, установив ACL-доступ в каждом подкаталоге, содержащем запись собственной группы и именованной группы:

country=CN
group::rwx
group:sales_CN:r-x

country=GB
group::rwx
group:sales_GB:r-x

country=US
group::rwx
group:sales_US:r-x

Important

Функциональность записи ACL группы-владельца (запись группы без имени) эквивалентна установленным Permission Bits

Авторизация на основе хранилища в Hive в настоящее время не учитывает разрешения ACL в HDFS. Доступ проверяется с использованием традиционной модели разрешений POSIX.

ACL по умолчанию

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

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

default:user::rwx
default:user:bruce:rw-
default:user:diana:r--
default:user:clark:rw-
default:group::r--
default:group:sales::rw-
default:group:execs::rw-
default:others::---

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

ACL/Permissions Only

Списки управления доступом HDFS поддерживают развертывания, в которых может потребоваться использование только битов разрешений, а не ACL с именованными записями пользователей и групп. Permission Bits эквивалентны минимальному ACL, содержащему только 3 записи. Например:

user::rw-
group::r--
others::---

Блокировка доступа для пользователя

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

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

dir1
`-- dir2
    `-- dir3
        |-- file1
        |-- file2
        `-- file3

Установка следующего ACL на dir2 блокирует доступ Брюса к dir3, file1, file2 и file3:

user:bruce:---

Удаление разрешений на dir2 означает, что Брюс не может получить к нему доступ и, следовательно, не может видеть ни один из его дочерних элементов. Это также означает, что доступ автоматически блокируется для любых вновь добавленных файлов в dir2. То есть если file4 создается под dir3, Брюс не сможет получить к нему доступ.

Sticky Bit

Когда нескольким именованным пользователям или группам требуется полный доступ к каталогу общего назначения, например, / tmp. Однако разрешения “Write” и “Execute” для каталога также дают пользователям возможность удаления или переименовывания любых файлов в каталоге, включая созданные другими пользователями. Такие разрешения необходимо ограничить, чтобы у пользователей был допуск на удаление или переименование созданных только ими файлов.

Этот случай можно решить, объединив ACL с Sticky bit – это существующая функциональность, которая в настоящее время работает с Permission Bits, и будет продолжать работать как ожидается в сочетании с ACL.