Ошибка авторизации 403 Access Denied, если бит липкий включен в ADLS 2-го поколения
В этой статье показано, как проверить этот параметр при настройке в Azure Data Lake Storage (ADLS) 2-го поколения и получить проблемы.
Что такое липкий бит в ADLS 2-го поколения?
Пользователям ADLS 2-го поколения часто требуется управлять разрешениями для разных пользователей, а одним из способов этого является использование списка управления доступом (ACL). ACL — это система управления доступом, похожая на POSIX, с определенным параметром, который называется липким битом, который может привести к сбоям авторизации. Дополнительные сведения о режиме управления разрешениями и бите слипкой см. в списках управления доступом (ACL) в Azure Data Lake Storage 2-го поколения.
Липкий бит — это расширенная функция, которая не требуется в параметре ACL учетной записи хранения ADLS 2-го поколения. Вместо этого можно использовать функцию маски, чтобы ограничить максимальные разрешения именованных пользователей, именованных групп и группы владельцев. Это работает аналогично липкой бите и легко настраивается в портал Azure.
Ошибка авторизации отказано в доступе 403
Рассмотрим следующий сценарий:
- Учетная запись хранения ADLS 2-го поколения содержит контейнер, называемый контейнером , и путь к папке с именем folder/child-folder.
- ACL используется в качестве метода авторизации.
- В параметре ACL учетной записи хранения ADLS 2-го поколения вы настроили разрешение Execute (X) в корневом каталоге и папке, а также разрешение на запись и выполнение (WX) в дочерней папке.
- Липкий бит включен в дочерней папке.
- Вы пытаетесь создать или отправить новый файл, например , test.txt, в папку adLS 2-го поколения путь к папке, контейнер или папку/дочерние папки/.
В этом сценарии вы получите ошибку авторизации с отказом в доступе 403.
Эта ошибка возникает по двум причинам:
- У вас недостаточно разрешений для доступа к пути к папке.
- У вас достаточно разрешений, но включение липких битов приводит к тому, что вы не будете владельцем этого пути к папке.
Определите, вызывает ли липкая бита ошибку 403 Access Denied
Проверьте параметр ACL папки и родительских папок, а затем сравните его с общими сценариями, связанными с разрешениями ACL. Если достаточно разрешений, ошибка 403 может быть вызвана липким битом.
Проверка параметров липких битов с помощью Azure CLI
Существует множество способов проверить этот параметр, например вызов REST API, команду PowerShell и Azure CLI. Мы рекомендуем использовать параметр Azure CLI, так как он не требует установки дополнительного программного обеспечения, и команда легко понять.
Чтобы проверить параметры липких битов с помощью Azure CLI, выполните следующие действия.
Войдите в портал Azure с помощью учетной записи. Убедитесь, что эта учетная запись имеет назначение роли владельца данных BLOB-объектов хранилища в учетной записи хранения ADLS 2-го поколения.
Выберите Cloud Shell из портал Azure.
Используйте следующую команду, чтобы получить ACL и параметр липкой битовой части каталога контейнера или папки :
az storage fs access show -p folder -f container --account-name account --auth-mode loginЧтобы проверить ACL и липкий битовый параметр корневого каталога, который является ACL уровня контейнера и параметром липкой биты, используйте следующую команду:
az storage fs access show -p / -f container --account-name account --auth-mode loginНиже приведен пример выходных данных.
В тексте JSON ответа сосредоточьтесь на
permissions. Обычно он содержит 9 или 10 бит с дополнительным символом "+". Дополнительные сведения об этих письмах см. в разделе "Пользователи и удостоверения".В предыдущем примере указано, что все разрешения пользователя включены, а бит слипки включен. Дополнительные сведения о том, как прочитать эту нотацию разрешений, см. в нотации традиционных разрешений Unix.
Девятая буква имеет четыре возможных значения: "-", "x", "t" и "T". Если значение этого буквы равно "t" или "T", это означает, что липкий бит включен. Значение "t" имеет значение "x" с включенным битом липких битов, а "T" — "-" с включенным битом.
"rwxrwxrwt" можно объяснить следующим образом:
- Разрешения r,w и x включены для владельца.
- Разрешения r,w и x включены для группы владения.
- Разрешения r,w и x включены для других пользователей, а бит липкий включен.
Чтобы лучше понять это, вот еще один пример для rwxr-xr-T:
- Разрешения r,w и x включены для владельца.
- Разрешения r и x включены для группы владельцев.
- Для других пользователей включено только разрешение r, и включена липкая бита.
Согласно коротким формам для разрешений, разрешение на короткую форму вычисляется для каждой группы трех букв ("r" как 4, "w" как 2 и "x "как 1"). Таким образом, "rw-rwx--x" будет равен 4+2+0, 4+2+1, 0+0+1, 671. На основе этого правила вычисления необходимо добавить только четвертую букву в начале. Если липкий бит включен, установите его как 1. Если липкий бит отключен, установите его как 0.
Далее приводятся некоторые примеры.
- rwxrwxrwwt => 1777
- rwxr-xr-T => 1754
- rw-rwx--x => 0671
Отключение и включение параметров битовой липких битов
Чтобы отключить или включить параметр липких битов, задайте разрешения ожидаемым значениям.
Учетная запись Azure, используемая для изменения этого параметра, должна иметь роль владельца данных BLOB-объектов хранилища в целевой учетной записи хранения ADLS 2-го поколения. Существует множество возможных способов изменения строго битового параметра. Ниже приведены поддерживаемые пакеты SDK:
Ниже приведен пример отключения или включения битового параметра с помощью Azure CLI.
Войдите в портал Azure с учетной записью с назначением роли владельца данных BLOB-объектов хранилища в целевой учетной записи хранения ADLS 2-го поколения.
Выберите Cloud Shell из портал Azure.
Чтобы задать ACL и липкий битовый параметр каталога контейнера или папки разрешения rwxrwxrwt и включить липкий бит, используйте следующую команду:
az storage fs access set --permissions rwxrwxrwt -p folder -f container --account-name account --auth-mode loginЧтобы изменить параметр корневого каталога, который является ACL уровня контейнера и параметром липкой биты, используйте следующую команду:
az storage fs access set --permissions rwxrwxrwt -p / -f container --account-name account --auth-mode loginВ
{permission notation}предыдущей команде могут приниматься как длинные, так и короткие нотации. Это означает, что следующая команда также квалифицирована:az storage fs access set --permissions 1776 -p folder -f container --account-name account --auth-mode loginНиже представлен пример результата.
Свяжитесь с нами для получения помощи
Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.