ACLs (listas de controle de acesso) no Azure Data Lake Storage

Artigo
12/03/2024

O Azure Data Lake Storage implementa um modelo de controle de acesso que oferece suporte ao controle de acesso baseado em função do Azure (RBAC do Azure) e listas de controle de acesso (ACLs) semelhantes a POSIX. Este artigo descreve as listas de controle de acesso no Data Lake Storage. Para saber mais sobre como incorporar o RBAC do Azure junto com ACLs e como o sistema os avalia para tomar decisões de autorização, consulte Modelo de controle de acesso no Azure Data Lake Storage.

Sobre ACLs

Você pode associar uma entidade de segurança a um nível de acesso para arquivos e diretórios. Cada associação é capturada como uma entrada em uma ACL (lista de controle de acesso) . Cada arquivo e diretório na sua conta de armazenamento tem uma lista de controle de acesso. Quando uma entidade de segurança tenta executar uma operação em um arquivo ou diretório, uma verificação ACL determina se a entidade de segurança (usuário, grupo, entidade de serviço ou identidade gerenciada) tem o nível de permissão correto para executar a operação.

Observação

As ACLs se aplicam somente a entidades de segurança no mesmo locatário. As ACLs não se aplicam a usuários que usam a autorização de Chave Compartilhada porque nenhuma identidade está associada ao chamador e, portanto, a autorização baseada em permissão da entidade de segurança não pode ser executada. O mesmo vale para tokens SAS (assinatura de acesso compartilhado), exceto quando um token SAS delegado pelo usuário é usado. Nesse caso, o Armazenamento do Microsoft Azure executa uma verificação de ACL POSIX na ID do objeto antes de autorizar a operação, desde que o parâmetro opcional suoid seja usado. Para saber mais, confira Construir uma SAS de delegação de usuário.

Como definir ACLs

Para definir permissões de nível de arquivo e diretório, consulte qualquer um dos seguintes artigos:

Ambiente	Artigo
Gerenciador de Armazenamento do Azure	Usar o Gerenciador de Armazenamento do Azure para gerenciar o acesso no Azure Data Lake Storage
Portal do Azure	Usar o portal do Azure para gerenciar ACLs no Azure Data Lake Storage
.NET	Usar .NET para gerenciar ACLs no Azure Data Lake Storage
Java	Usar Java para gerenciar ACLs no Azure Data Lake Storage
Python	Usar o Python para gerenciar ACLs no Azure Data Lake Storage
JavaScript (Node.js)	Usar o SDK do JavaScript em Node.js para gerenciar ACLs no Azure Data Lake Storage
PowerShell	Usar o PowerShell para gerenciar ACLs no Azure Data Lake Storage
CLI do Azure	Usar a CLI do Azure para gerenciar ACLs no Azure Data Lake Storage
API REST	Caminho - Atualizar

Importante

Se a entidade de segurança for uma entidade de serviço, é importante usar a ID de objeto da entidade de serviço e não a ID de objeto do registro do aplicativo relacionado. Para obter a ID de objeto da entidade de serviço, abra o CLI do Azure e, em seguida, use este comando: az ad sp show --id <Your App ID> --query objectId. Certifique-se de substituir o espaço reservado <Your App ID> pelo ID do aplicativo do registro do aplicativo. A entidade de serviço é tratada como um usuário nomeado. Você adicionará esse ID à ACL como faria com qualquer usuário nomeado. Os usuários nomeados são descritos posteriormente neste artigo.

Tipos de ACLs

Há dois tipos de listas de controle de acesso: ACLs de Acesso e ACLs Padrão.

ACLs de acesso controlam o acesso a um objeto. Arquivos e diretórios têm ambos ACLs de acesso.

ACLs padrão são modelos de ACLs associados a um diretório que determina as ACLs de acesso para todos os itens filho criados nesse diretório. Arquivos não têm ACLs padrão.

As ACLs de Acesso e as ACLs Padrão têm a mesma estrutura.

Observação

Alterar a ACL Padrão em um pai não afeta o a ACL de Acesso ou a ACL Padrão de itens filhos já existentes.

Níveis de permissão

As permissões em diretórios e arquivos em um contêiner são de Leitura, Gravação, e Execução e podem ser usadas em arquivos e diretórios, conforme mostrado na seguinte tabela:

	Arquivo	Diretório
Ler (R)	Pode ler o conteúdo de um arquivo	Requer Ler e Executar para listar o conteúdo do diretório
Gravar (W)	Pode gravar ou anexar a um arquivo	Requer Gravar e Executar para criar itens filhos em um diretório
Executar (X)	Não significa nada no contexto do Data Lake Storage	Necessário para percorrer os itens filhos de um diretório

Observação

Se você estiver concedendo permissões usando somente ACLs (sem Azure RBAC), para conceder a uma entidade de segurança acesso de leitura ou de gravação a um arquivo, você precisará fornecer à entidade de segurança permissões de execução para a pasta raiz do contêiner e para cada pasta na hierarquia de pastas que levam ao arquivo.

Formatos abreviados para permissões

RWXé usado para indicar Ler + Gravar + Executar. Existe um formato numérico mais condensado na qual Ler = 4, Gravar = 2 e Executar = 1 e sua soma representa as permissões. Estes são alguns exemplos:

Formato numérico	Formato curto	O que significa
7	`RWX`	Ler + Gravar + Executar
5	`R-X`	Ler + Executar
4	`R--`	Ler
0	`---`	Nenhuma permissão

Herança de permissões

No modelo de estilo POSIX usado pelo Data Lake Storage, as permissões para um item são armazenadas no próprio item. Em outras palavras, as permissões para um item não podem ser herdadas dos itens pai se as permissões são definidas depois que o item filho já foi criado. As permissões são herdadas somente se as permissões padrão tiverem sido definidas nos itens pai antes dos itens filho terem sido criados.

A tabela a seguir mostra as entradas de ACL necessárias para habilitar uma entidade de segurança para executar as operações listadas na coluna Operação.

Esta tabela mostra uma coluna que representa cada nível de uma hierarquia de diretório fictícia. Há uma coluna para o diretório raiz do contêiner (/), um subdiretório chamado Oregon, um subdiretório do diretório Oregon chamado Portlande um arquivo de texto no diretório Portland chamado Data.txt.

Importante

Esta tabela pressupõe que você está usando somente ACLs sem nenhuma atribuição de função do Azure. Para ver uma tabela semelhante que combina o Azure RBAC com ACLs, confira Tabela de permissões: combinando o Azure RBAC, ABAC e ACLs.

Operação	/	Oregon/	Portland/	Data.txt
Read Data.txt	`--X`	`--X`	`--X`	`R--`
Append to Data.txt	`--X`	`--X`	`--X`	`RW-`
Delete Data.txt	`--X`	`--X`	`-WX`	`---`
Excluir /Oregon/	`-WX`	`RWX`	`RWX`	`---`
Excluir /Oregon/Portland/	`--X`	`-WX`	`RWX`	`---`
Criar / Atualizar Data.txt	`--X`	`--X`	`-WX`	`---`
List /	`R-X`	`---`	`---`	`---`
Lista /Oregon/	`--X`	`R-X`	`---`	`---`
Lista /Oregon/Portland/	`--X`	`--X`	`R-X`	`---`

Excluindo arquivos e diretórios

Conforme mostrado na tabela anterior, as permissões de gravação no arquivo não são necessárias para excluí-lo, contanto que as permissões do diretório estejam configuradas corretamente. No entanto, para excluir um diretório e todo o seu conteúdo, o diretório pai deve ter permissões Gravar + Executar. O diretório a ser excluído, e todas as pastas nela, exige permissões Ler + Gravar + Executar.

Observação

O diretório raiz "/" nunca pode ser excluído.

Usuários e identidades

Todos os arquivos e diretórios têm permissões diferentes para estas identidades:

O usuário proprietário
O grupo proprietário
Usuários nomeados
Grupos nomeados
Todas as entidades de serviço
Identidades gerenciadas nomeadas
Todos os outros usuários

As identidades de usuários e grupos são identidades do Microsoft Entra. Portanto, a menos que indicado o contrário, um usuário, no contexto do Azure Data Lake Storage, pode se referir a um usuário do Microsoft Entra, entidade de serviço, identidade gerenciada ou grupo de segurança.

O superusuário

Um superusuário tem a maioria dos direitos de todos os usuários. Um superusuário:

Tem Permissões RWX para todos os arquivos e pastas.
Pode alterar as permissões em qualquer arquivo ou pasta.
Pode alterar o usuário proprietário ou o grupo proprietário de qualquer arquivo ou pasta.

Se um contêiner, arquivo ou diretório for criado usando a chave compartilhada, um SAS de conta ou um SAS de serviço, o proprietário e o grupo proprietário serão definidos como $superuser.

O usuário proprietário

O usuário que criou o item é automaticamente o usuário proprietário do item. Um usuário proprietário pode:

Altere as permissões de um arquivo pertencente.
Alterar o grupo proprietário de um arquivo pertencente, contanto que o usuário proprietário também seja membro do grupo de destino.

Observação

O usuário proprietário não pode alterar o usuário proprietário de um arquivo ou diretório. Somente superusuários podem alterar o usuário proprietário de um arquivo ou diretório.

O grupo proprietário

Nas ACLs do POSIX, cada usuário está associado a um grupo primário. Por exemplo, o usuário "Alice" pode pertencer ao grupo "finanças". Alice pode pertencer também a vários grupos, mas um grupo será sempre designado como o grupo primário dela. No POSIX, quando Alice cria um arquivo, o grupo de propriedade desse arquivo é definido como seu grupo principal, que, nesse caso, é "finanças". Caso contrário, o grupo de propriedade se comporta de forma semelhante às permissões atribuídas a outros usuários/grupos.

Atribuindo o grupo proprietário de um novo arquivo ou diretório

Caso 1: o diretório raiz /. Esse diretório é criado quando um contêiner do Azure Data Lake Storage é criado. Nesse caso, o grupo proprietário é definido para o usuário que criou o contêiner se tivesse sido feito usando o OAuth. Se o contêiner é criado usando a chave compartilhada, uma Conta SAS, ou Serviço SAS, então o proprietário ou grupo de proprietário são definidos para o $superuser.
Caso 2 (Todos os outros casos): quando um item é criado, o grupo proprietário é copiado da pasta pai.

Alterando o grupo proprietário

O grupo proprietário pode ser alterado por:

Todos os superusuários.
O usuário proprietário, se o usuário proprietário também for membro do grupo de destino.

Observação

O usuário proprietário não pode alterar as ACLs de um arquivo ou um diretório. Embora o grupo proprietário esteja definido para o usuário que criou a conta no caso do diretório raiz, Caso 1 acima, uma conta de usuário individual não é válida para fornecer permissões através do grupo proprietário. Você pode atribuir essa permissão a um grupo de usuários válido, se for aplicável.

Como as permissões são avaliadas

As identidades são avaliadas na seguinte ordem:

Superusuário
Usuário proprietário
Usuário, entidade de serviço ou identidade gerenciada
Grupo de propriedade ou grupo nomeado
Todos os outros usuários

Se mais de uma dessas identidades se aplicar a uma entidade de segurança, o nível de permissão associado à primeira identidade será concedido. Por exemplo, se uma entidade de segurança for o usuário proprietário e um usuário nomeado, o nível de permissão associado ao usuário proprietário será aplicado.

Grupos nomeados são todos considerados juntos. Se uma entidade de segurança for membro de mais de um grupo nomeado, o sistema avaliará cada grupo até que a permissão desejada seja concedida. Se nenhum dos grupos nomeados fornecer a permissão desejada, o sistema avaliará uma solicitação em relação à permissão associada a todos os outros usuários.

O pseudocódigo a seguir representa o algoritmo de verificação de acesso das contas para contas de armazenamento. Esse algoritmo mostra a ordem na qual as identidades são avaliadas.

def access_check( user, desired_perms, path ) :
  # access_check returns true if user has the desired permissions on the path, false otherwise
  # user is the identity that wants to perform an operation on path
  # desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
  # path is the file or directory
  # Note: the "sticky bit" isn't illustrated in this algorithm

  # Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask isn't used.
  entry = get_acl_entry( path, OWNER )
  if (user == entry.identity)
      return ( (desired_perms & entry.permissions) == desired_perms )

  # Handle the named users. Note that mask IS used.
  entries = get_acl_entries( path, NAMED_USER )
  for entry in entries:
      if (user == entry.identity ) :
          mask = get_mask( path )
          return ( (desired_perms & entry.permissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  mask = get_mask( path )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
        if ((desired_perms & entry.permissions & mask) == desired_perms)
            return True

  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

A máscara

A máscara se aplica somente à entrada ACL de um usuário nomeado, grupo nomeado e grupo proprietário. A máscara especifica quais das permissões na entrada ACL são usadas para autorizar o acesso. Essas permissões aplicadas são chamadas de permissões efetivas da entrada ACL. Todas as outras permissões na entrada ACL são ignoradas. Ao usar a máscara, você pode estabelecer um limite máximo nos níveis de permissão.

A máscara pode ser especificada em uma base por chamada. Isso permite que diferentes sistemas de consumo, como clusters, ter diferentes máscaras eficazes para suas operações de arquivo. Se uma máscara for especificada em uma determinada solicitação, ela substitui completamente a máscara padrão.

O sticky bit

O sticky bit é um recurso mais avançado de um contêiner POSIX. No contexto do Data Lake Storage, é improvável que o sticky bit seja necessário. Em resumo, se o sticky bit estiver ativado em um diretório, um item filho somente poderá ser excluído ou renomeado pelo usuário proprietário do item filho, pelo proprietário do diretório ou pelo superusuário ($superusuário).

O sticky bit não é mostrado no Portal do Azure. Para saber mais sobre o bit autoadesivo e como defini-lo, consulte Qual é o bit autoadesivo do Data Lake Storage?.

Permissões padrão do diretório raiz

Para um novo contêiner do Data Lake Storage, a ACL de acesso do diretório raiz ("/") assume como padrão 750 para diretórios e 640 para arquivos. A tabela a seguir mostra a notação simbólica desses níveis de permissão.

Entidade	Diretórios	Arquivos
Usuário proprietário	`rwx`	`rw-`
Grupo proprietário	`r-x`	`r--`
Outro	`---`	`---`

Arquivos não recebem o bit X uma vez que é irrelevante para arquivos em um sistema de armazenamento somente.

Permissões padrão em novos arquivos e diretórios

Quando um novo arquivo ou pasta é criado em um diretório existente, a ACL Padrão no diretório pai determina:

ACL Padrão e ACL de Acesso de um diretório filho.
ACL de Acesso de um arquivo filho (os arquivos não têm uma ACL Padrão).

umask

Ao criar uma ACL padrão, o umask é aplicado à ACL de acesso para determinar as permissões iniciais de uma ACL padrão. Se uma ACL padrão for definida no diretório pai, o umask será efetivamente ignorado e a ACL padrão do diretório pai será usada para definir esses valores iniciais.

O umask é um valor de 9 bits nas pastas pai que contém um valor de RWX para o usuário proprietário, o grupo proprietário e outros.

O umask do Azure Data Lake Storage é um valor constante definido como 007. Esse valor é convertido em:

Componente umask	Formato numérico	Formato curto	Significado
umask.owning_user	0	`---`	Para o usuário proprietário, copie a ACL de acesso do pai para a ACL de padrão do filho
umask.owning_group	0	`---`	Para o grupo proprietário, copie a ACL de acesso do pai para a ACL padrão do filho
umask.other	7	`RWX`	Para outros, remova todas as permissões na ACL de Acesso do filho

Perguntas frequentes

É necessário habilitar o suporte para ACLs?

Não. O controle de acesso via ACLs está habilitado para uma conta de armazenamento assim que o recurso do Namespace hierárquico (HNS) é ativado.

Se HNS estiver desativado, as regras de autorização do RBAC do Azure ainda se aplicam.

Qual é a melhor maneira de aplicar ACLs?

Sempre use grupos de segurança do Microsoft Entra como a entidade de segurança atribuída em uma entrada de ACL. Resista a oportunidade de atribuir diretamente a usuários individuais ou entidades de serviço. Usar essa estrutura permitirá que você adicione e remova usuários ou entidades de serviço sem a necessidade de reaplicar as ACLs para uma estrutura de diretório inteiro. Em vez disso, você pode apenas adicionar ou remover usuários e entidades de serviço do grupo de segurança apropriado do Microsoft Entra.

Existem muitas maneiras diferentes de configurar grupos. Por exemplo, imagine que você tenha um diretório chamado /LogData que contém dados de log gerados pelo servidor. O ADF (Azure Data Factory) ingere dados para essa pasta. Usuários específicos da equipe de engenharia de serviço carregarão logs e gerenciarão outros usuários dessa pasta e vários clusters do Databricks analisarão os logs dessa pasta.

Para habilitar essas atividades, você pode criar um grupo LogsWriter e um grupo LogsReader. Em seguida, você pode atribuir permissões da seguinte maneira:

Adicione o LogsWriter grupo à ACL do diretório /LogData com rwx permissões.
Adicione o LogsReader grupo à ACL do diretório /LogData com r-x permissões.
Adicione o objeto de entidade de serviço ou MSI (Identidade de Serviço Gerenciado) do ADF ao grupo LogsWriters.
Adicione usuários na equipe de engenharia de serviço ao grupo LogsWriter.
Adicione o objeto de entidade de serviço ou MSI para Databricks ao grupo LogsReader.

Se um usuário na equipe de engenharia de serviço sair da empresa, você poderá removê-lo do grupo LogsWriter. Se você não adicionasse esse usuário a um grupo, mas, em vez disso, adicionasse uma entrada ACL dedicada para esse usuário, você precisaria remover essa entrada ACL do diretório /LogData. Você também precisaria remover a entrada de todos os subdiretórios e arquivos na hierarquia de diretório inteira do diretório /LogData.

Para criar um grupo e adicionar membros, confira Criar um grupo básico e adicionar membros usando o Microsoft Entra ID.

Importante

O Azure Data Lake Storage Gen2 depende do Microsoft Entra ID para gerenciar grupos de segurança. O Microsoft Entra ID recomenda que você limite a associação de grupo para uma determinada entidade de segurança para menos de 200. Essa recomendação ocorre devido a uma limitação de JWT (Tokens Web JSON) que fornecem informações de associação de grupo de uma entidade de segurança em aplicativos do Microsoft Entra. Exceder esse limite poderá resultar em problemas de desempenho inesperado com o Data Lake Storage Gen2. Para saber mais, confira Configurar declarações de grupo para aplicativos usando o Microsoft Entra ID.

Como as permissões de RBAC e ACL do Azure são avaliadas?

Para saber como o sistema avalia o RBAC e as ACLs do Azure juntos para tomar decisões de autorização para recursos de conta de armazenamento, consulte Como as permissões são avaliadas.

Quais são os limites para as atribuições de função do Azure e as entradas de ACL?

A tabela a seguir fornece uma exibição resumida dos limites a serem considerados ao usar o Azure RBAC para gerenciar permissões "de alta granularidade" (permissões que se aplicam a contêineres ou contas de armazenamento) e usando ACLs para gerenciar permissões "refinadas" (permissões que se aplicam a arquivos e diretórios). Use grupos de segurança para atribuições de ACL. Usando grupos, você tem menor probabilidade de exceder o número máximo de atribuições de função por assinatura e o número máximo de entradas de ACL por arquivo ou diretório.

Mecanismo	Escopo	Limites	Nível de permissão com suporte
RBAC do Azure	Contas de armazenamento, contêineres. Atribuições de função do Azure entre recursos no nível de assinatura ou grupo de recursos.	4.000 atribuições de função do Azure em uma assinatura	Funções do Azure (internas ou personalizadas)
ACL	Diretório, arquivo	32 entradas de ACL (efetivamente 28 entradas de ACL) por arquivo e por diretório. As ACLs de acesso e padrão têm seu próprio limite de entrada de ACL 32.	Permissão de ACL

O Azure Data Lake Storage dá suporte à herança de Azure RBAC?

Herda as atribuições de função do Azure. Atribuições fluem de assinatura, grupo de recursos e recursos da conta de armazenamento até o recurso de contêiner.

O Data Lake Storage dá suporte à herança de ACLs?

As ACLs padrão podem ser usadas para definir as ACLs de subdiretórios filho e arquivos criados no diretório pai. Para atualizar ACLs para itens filho existentes, você precisará adicionar, atualizar ou remover ACLs recursivamente para a hierarquia de diretório desejada. Para obter diretrizes, consulte a seção como definir ACLs deste artigo.

Quais são as permissões necessárias para excluir recursivamente um diretório e seu conteúdo?

O chamador tem permissões de “superusuário”,

A pasta diretório deve ter permissões Gravar + Executar.
O diretório a ser excluído, e todas as pastas nela, exige permissões Ler + Gravar + Executar.

Observação

Você não precisa de permissões de gravação para excluir arquivos em diretórios. Além disso, a pasta raiz "/" nunca poderá ser excluída.

Quem é o proprietário de um arquivo ou diretório?

O criador de um arquivo ou diretório se torna o proprietário. No caso do diretório raiz, esta é a identidade do usuário que criou o contêiner.

Qual grupo é definido como grupo proprietário de um arquivo ou diretório na criação?

O grupo pertencente é copiado do grupo proprietário do diretório pai na qual o novo arquivo ou diretório é criado.

Eu sou o usuário proprietário de um arquivo, mas não tenho as permissões RWX de que necessito. O que devo fazer?

O usuário proprietário pode alterar as permissões do arquivo para atribuir a sim mesmo quaisquer permissões RWX necessárias.

Por que, às vezes, vejo GUIDs nas ACLs?

Um GUID será mostrado se a entrada representa um usuário e esse usuário não existir mais no Microsoft Entra. Geralmente isso acontece se o usuário tiver deixado a empresa ou se sua conta tiver sido excluída no Microsoft Entra ID. Além disso, as entidades de serviço e grupos de segurança não tem um nome Principal de Usuário (UPN) para identificá-lo e então, são representados por seu atributo de identificação de objeto (um guid). Para limpar as ACLs, exclua manualmente essas entradas GUID.

Como fazer definir ACLs corretamente para uma entidade de serviço?

Quando você define ACLs para entidades de serviço, é importante usar a ID de objeto (OID) da entidade de serviço para o registro do aplicativo que você criou. É importante observar que os aplicativos registrados têm uma entidade de serviço separada no locatário específico do Microsoft Entra. Os aplicativos registrados têm uma OID que é visível no portal do Azure, mas a entidade de serviço tem outra OID (diferente). Artigo Para obter o OID para a entidade de serviço que corresponde a um registro de aplicativo, você pode usar o comando az ad sp show. Especifique a ID do aplicativo como o parâmetro. Veja um exemplo de obtenção do OID para a entidade de serviço que corresponde a um registro de aplicativo com a ID de Aplicativo = 00001111-aaaa-2222-bbbb-3333cccc4444. Execute o seguinte comando na CLI do Azure:

az ad sp show --id 00001111-aaaa-2222-bbbb-3333cccc4444 --query objectId

A OID será exibida.

Quando você tiver a OID correta para a entidade de serviço, vá para a página Gerenciador de Armazenamento Gerenciar acesso para adicionar a OID e atribuir as permissões apropriadas para a OID. Escolha Salvar

Posso definir a ACL de um contêiner?

Não. Um contêiner não tem uma ACL. No entanto, você pode definir a ACL do diretório raiz do contêiner. Cada contêiner tem um diretório raiz e compartilha o mesmo nome que o contêiner. Por exemplo, se o contêiner for nomeado my-container, o diretório raiz será nomeado my-container/.

A API REST do armazenamento do Azure contém uma operação denominada Definir ACL de contêiner, mas essa operação não pode ser usada para definir a ACL de um contêiner ou o diretório raiz de um contêiner. Em vez disso, essa operação é usada para indicar se os blobs em um contêiner podem ser acessados com uma solicitação anônima. É recomendável exigir autorização para todas as solicitações para dados de blob. Para obter mais informações, consulte Visão geral: Corrigir o acesso de leitura anônimo para dados de blob.

Onde posso saber mais sobre o modelo de controle de acesso do POSIX?

Confira também

Modelo de controle de acesso no Azure Data Lake Storage

Compartilhar via

ACLs (listas de controle de acesso) no Azure Data Lake Storage

Sobre ACLs

Como definir ACLs

Tipos de ACLs

Níveis de permissão

Formatos abreviados para permissões

Herança de permissões

Excluindo arquivos e diretórios

Usuários e identidades

O superusuário

O usuário proprietário

O grupo proprietário

Atribuindo o grupo proprietário de um novo arquivo ou diretório

Alterando o grupo proprietário

Como as permissões são avaliadas

A máscara

O sticky bit

Permissões padrão do diretório raiz

Permissões padrão em novos arquivos e diretórios

umask

Perguntas frequentes

É necessário habilitar o suporte para ACLs?

Qual é a melhor maneira de aplicar ACLs?

Como as permissões de RBAC e ACL do Azure são avaliadas?

Quais são os limites para as atribuições de função do Azure e as entradas de ACL?

O Azure Data Lake Storage dá suporte à herança de Azure RBAC?

O Data Lake Storage dá suporte à herança de ACLs?

Quais são as permissões necessárias para excluir recursivamente um diretório e seu conteúdo?

Quem é o proprietário de um arquivo ou diretório?

Qual grupo é definido como grupo proprietário de um arquivo ou diretório na criação?

Eu sou o usuário proprietário de um arquivo, mas não tenho as permissões RWX de que necessito. O que devo fazer?

Por que, às vezes, vejo GUIDs nas ACLs?

Como fazer definir ACLs corretamente para uma entidade de serviço?

Posso definir a ACL de um contêiner?

Onde posso saber mais sobre o modelo de controle de acesso do POSIX?

Confira também

Comentários

Recursos adicionais

Compartilhar via

ACLs (listas de controle de acesso) no Azure Data Lake Storage

Sobre ACLs

Como definir ACLs

Tipos de ACLs

Níveis de permissão

Formatos abreviados para permissões

Herança de permissões

Cenários comuns relacionados a permissões ACL

Excluindo arquivos e diretórios

Usuários e identidades

O superusuário

O usuário proprietário

O grupo proprietário

Atribuindo o grupo proprietário de um novo arquivo ou diretório

Alterando o grupo proprietário

Como as permissões são avaliadas

A máscara

O sticky bit

Permissões padrão do diretório raiz

Permissões padrão em novos arquivos e diretórios

umask

Perguntas frequentes

É necessário habilitar o suporte para ACLs?

Qual é a melhor maneira de aplicar ACLs?

Como as permissões de RBAC e ACL do Azure são avaliadas?

Quais são os limites para as atribuições de função do Azure e as entradas de ACL?

O Azure Data Lake Storage dá suporte à herança de Azure RBAC?

O Data Lake Storage dá suporte à herança de ACLs?

Quais são as permissões necessárias para excluir recursivamente um diretório e seu conteúdo?

Quem é o proprietário de um arquivo ou diretório?

Qual grupo é definido como grupo proprietário de um arquivo ou diretório na criação?

Eu sou o usuário proprietário de um arquivo, mas não tenho as permissões RWX de que necessito. O que devo fazer?

Por que, às vezes, vejo GUIDs nas ACLs?

Como fazer definir ACLs corretamente para uma entidade de serviço?

Posso definir a ACL de um contêiner?

Onde posso saber mais sobre o modelo de controle de acesso do POSIX?

Confira também

Comentários

Recursos adicionais