Compreender as listas de controle de acesso NFSv4.x nos Arquivos NetApp do Azure

Artigo
11/19/2023

O protocolo NFSv4.x pode fornecer controle de acesso na forma de listas de controle de acesso (ACLs), que conceitualmente são semelhantes às ACLs usadas no SMB por meio de permissões NTFS do Windows. Uma ACL NFSv4.x consiste em entradas de controle de acesso (ACEs) individuais, cada uma das quais fornece uma diretiva de controle de acesso para o servidor.

Cada ACL NFSv4.x é criada com o formato de type:flags:principal:permissions.

Tipo – o tipo de ACL que está sendo definido. As opções válidas incluem Acesso (A), Negar (D), Auditoria (U), Alarme (L). Os Arquivos NetApp do Azure dão suporte aos tipos de ACL de Acesso, Negação e Auditoria, mas as ACLs de Auditoria, embora possam ser definidas, atualmente não produzem logs de auditoria.
Sinalizadores – adiciona contexto extra para uma ACL. Existem três tipos de sinalizadores ACE: grupo, herança e administrativo. Para obter mais informações sobre sinalizadores, consulte Sinalizadores ACE NFSv4.x.
Principal – define o usuário ou grupo ao qual está sendo atribuída a ACL. Uma entidade em uma ACL NFSv4.x usa o formato de name@ID-DOMAIN-STRING.COM. Para obter informações mais detalhadas sobre entidades de segurança, consulte Entidades de usuário e grupo NFSv4.x.
Permissões – onde o nível de acesso para a entidade de segurança é definido. Cada permissão é designada uma única letra (por exemplo, ler recebe "r", escrever recebe "w" e assim por diante). O acesso total incorporaria cada carta de permissão disponível. Para obter mais informações, consulte Permissões NFSv4.x.

A:g:group1@contoso.com:rwatTnNcCy é um exemplo de uma ACL válida, seguindo o type:flags:principal:permissions formato. A ACL de exemplo concede acesso total ao grupo group1 no domínio ID contoso.com.

Sinalizadores ACE NFSv4.x

Um sinalizador ACE ajuda a fornecer mais informações sobre um ACE em uma ACL. Por exemplo, se uma ACE de grupo for adicionada a uma ACL, um sinalizador de grupo precisará ser usado para designar que a entidade é um grupo e não um usuário. É possível em ambientes Linux ter um nome de usuário e um nome de grupo que são idênticos, então o sinalizador garante que um ACE seja honrado, então o servidor NFS precisa saber que tipo de entidade está sendo definida.

Outros sinalizadores podem ser usados para controlar ACEs, como heranças e sinalizadores administrativos.

Acessar e negar sinalizadores

Os sinalizadores de acesso (A) e negação (D) são usados para controlar os tipos de ACE de segurança. Uma ACE de acesso controla o nível de permissões de acesso em um arquivo ou pasta para uma entidade de segurança. Uma ACE de negação proíbe explicitamente uma entidade de segurança de acessar um arquivo ou pasta, mesmo que uma ACE de acesso esteja definida para permitir que essa entidade acesse o objeto. Negar ACEs sempre anular ACEs de acesso. Em geral, evite usar ACEs de negação, pois as ACLs NFSv4.x seguem um modelo de "negação padrão", ou seja, se uma ACL não for adicionada, a negação estará implícita. Negar ACEs pode criar complicações desnecessárias no gerenciamento do ACL.

Sinalizadores de herança

Os sinalizadores de herança controlam como as ACLs se comportam em arquivos criados abaixo de um diretório pai com o sinalizador de herança definido. Quando um sinalizador de herança é definido, os arquivos e/ou diretórios herdam as ACLs da pasta pai. Os sinalizadores de herança só podem ser aplicados a diretórios, portanto, quando um subdiretório é criado, ele herda o sinalizador. Os arquivos criados abaixo de um diretório pai com um sinalizador de herança herdam ACLs, mas não os sinalizadores de herança.

A tabela a seguir descreve os sinalizadores de herança disponíveis e seus comportamentos.

Sinalizador de herança	Comportamento
d	- Os diretórios abaixo do diretório pai herdam a ACL - A bandeira de herança também é herdada
f	- Os arquivos abaixo do diretório pai herdam a ACL - Os arquivos não definem o sinalizador de herança
posso	Somente herança; A ACL não se aplica ao diretório atual, mas deve aplicar herança a objetos abaixo do diretório
n	- Sem propagação de herança Depois que a ACL é herdada, os sinalizadores de herança são limpos nos objetos abaixo do pai

Exemplos de ACL NFSv4.x

No exemplo a seguir, há três ACEs diferentes com sinalizadores de herança distintos:

diretório herdar somente (di)
Somente herança de arquivo (FI)
Herança de arquivo e diretório (FDI)

# nfs4_getfacl acl-dir

# file: acl-dir/
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdi:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

User1 tem apenas uma ACL de herança de diretório. Em um subdiretório criado abaixo do pai, a ACL é herdada, mas em um arquivo abaixo do pai, não é.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file 
                       << ACL missing
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

User2 tem um sinalizador de herança de arquivo e diretório. Como resultado, os arquivos e diretórios abaixo de um diretório com essa entrada ACE herdam a ACL, mas os arquivos não herdam o sinalizador.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy << no flag
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

User3 só tem um sinalizador de herança de arquivo. Como resultado, apenas os arquivos abaixo do diretório com essa entrada ACE herdam a ACL, mas não herdam o sinalizador, pois ele só pode ser aplicado a ACEs de diretório.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy << no flag
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

Quando um sinalizador "no-propogate" (n) é definido em uma ACL, os sinalizadores são claros nas criações de diretório subsequentes abaixo do pai. No exemplo a seguir, user2 tem o n sinalizador definido. Como resultado, o subdiretório limpa os sinalizadores de herança para essa entidade e os objetos criados abaixo desse subdiretório não herdam a ACE de user2.

#  nfs4_getfacl /mnt/acl-dir

# file: /mnt/acl-dir
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdn:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

#  nfs4_getfacl inherit-dir/

# file: inherit-dir/
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A::user2@CONTOSO.COM:rwaDxtTnNcCy << flag cleared
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# mkdir subdir
# nfs4_getfacl subdir

# file: subdir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
<< ACL not inherited
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

Os sinalizadores de herança são uma maneira de gerenciar mais facilmente suas ACLs NFSv4.x, poupando-o de definir explicitamente uma ACL sempre que precisar de uma.

Bandeiras administrativas

Os sinalizadores administrativos em ACLs NFSv4.x são sinalizadores especiais que são usados apenas com os tipos de ACL de auditoria e alarme. Esses sinalizadores definem tentativas de acesso bem-sucedidas (S) ou fracassadas (F) para que as ações sejam executadas.

Os Arquivos NetApp do Azure dão suporte à configuração de sinalizadores administrativos para ACEs de Auditoria, no entanto, as ACEs não funcionam. Além disso, as ACEs de alarme não são suportadas nos Arquivos NetApp do Azure.

Entidades de usuário e grupo NFSv4.x

Com as ACLs NFSv4.x, as entidades de usuário e grupo definem os objetos específicos aos quais uma ACE deve se aplicar. Os diretores geralmente seguem um formato de name@ID-DOMAIN-STRING.COM. A parte "nome" de uma entidade de segurança pode ser um usuário ou grupo, mas esse usuário ou grupo deve ser resolúvel nos Arquivos NetApp do Azure por meio da conexão do servidor LDAP ao especificar o domínio de ID NFSv4.x. Se o name@domain não puder ser resolvido pelos Arquivos NetApp do Azure, a operação ACL falhará com um erro de "argumento inválido".

# nfs4_setfacl -a A::noexist@CONTOSO.COM:rwaxtTnNcCy inherit-file
Failed setxattr operation: Invalid argument

Você pode verificar nos Arquivos NetApp do Azure se um nome pode ser resolvido usando a lista de ID do grupo LDAP. Navegue até Suporte + Solução de Problemas e, em seguida, Lista de ID de Grupo LDAP.

Acesso de usuários e grupos locais via ACLs NFSv4.x

Usuários e grupos locais também podem ser usados em uma ACL NFSv4.x se apenas a ID numérica for especificada na ACL. Nomes de usuário ou IDs numéricos com um ID de domínio especificado falham.

Por exemplo:

# nfs4_setfacl -a A:fdg:3003:rwaxtTnNcCy NFSACL
# nfs4_getfacl NFSACL/
A:fdg:3003:rwaxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rwaDxtTnNcy
A::EVERYONE@:rwaDxtTnNcy

# nfs4_setfacl -a A:fdg:3003@CONTOSO.COM:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument

# nfs4_setfacl -a A:fdg:users:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument

Quando uma ACL de usuário ou grupo local é definida, qualquer usuário ou grupo que corresponda à ID numérica na ACL recebe acesso ao objeto. Para ACLs de grupo local, um usuário passa suas associações de grupo para Arquivos NetApp do Azure. Se a ID numérica do grupo com acesso ao arquivo por meio da solicitação do usuário for mostrada ao servidor NFS do Azure NetApp Files, o acesso será permitido de acordo com a ACL.

As credenciais passadas do cliente para o servidor podem ser vistas através de uma captura de pacotes, como visto abaixo.

Advertências:

Usar usuários e grupos locais para ACLs significa que cada cliente que acessa os arquivos/pastas precisa ter IDs de usuário e grupo correspondentes.
Ao usar uma ID numérica para uma ACL, os Arquivos NetApp do Azure confiam implicitamente que a solicitação de entrada é válida e que o usuário que solicita acesso é quem diz ser e é membro dos grupos dos quais afirma ser membro. Um usuário ou grupo numérico pode ser falsificado se um ator mal-intencionado souber a ID numérica e puder acessar a rede usando um cliente com a capacidade de criar usuários e grupos localmente.
Se um usuário for membro de mais de 16 grupos, qualquer grupo após o décimo sexto grupo (em ordem alfanumérica) terá acesso negado ao arquivo ou pasta, a menos que o LDAP e o suporte estendido ao grupo sejam usados.
As cadeias de caracteres LDAP e de nome de name@domain completo são altamente recomendadas ao usar ACLs NFSv4.x para melhor capacidade de gerenciamento e segurança. Um repositório de usuários e grupos gerenciado centralmente é mais fácil de manter e mais difícil de falsificar, tornando o acesso indesejado de usuários menos provável.

Domínio de ID NFSv4.x

O domínio de ID é um componente importante da entidade de segurança, onde um domínio de ID deve corresponder no cliente e nos Arquivos NetApp do Azure para que os nomes de usuário e grupo (especificamente, raiz) apareçam corretamente nas propriedades de arquivos/pastas.

Os Arquivos NetApp do Azure padronizam o domínio de ID NFSv4.x para as configurações de domínio DNS para o volume. Os clientes NFS também usam como padrão o domínio DNS para o domínio de ID NFSv4.x. Se o domínio DNS do cliente for diferente do domínio DNS dos Arquivos NetApp do Azure, ocorrerá uma incompatibilidade. Ao listar permissões de arquivo com comandos como ls, usuários/grupos aparecem como "ninguém".

Quando ocorrer uma incompatibilidade de domínio entre o cliente NFS e os Arquivos NetApp do Azure, verifique os logs do cliente em busca de erros semelhantes a:

August 19 13:14:29 nfsidmap[17481]: nss_getpwnam: name 'root@microsoft.com' does not map into domain ‘CONTOSO.COM'

O domínio de ID do cliente NFS pode ser substituído usando a configuração "Domínio" do arquivo /etc/idmapd.conf. Por exemplo: Domain = CONTOSO.COM.

Os Arquivos NetApp do Azure também permitem alterar o domínio de ID NFSv4.1. Para obter detalhes adicionais, consulte Como: Configuração de domínio de ID NFSv4.1 para arquivos NetApp do Azure.

Permissões NFSv4.x

As permissões NFSv4.x são a maneira de controlar o nível de acesso que um usuário ou entidade de grupo específico tem em um arquivo ou pasta. As permissões no NFSv3 permitem apenas níveis de leitura/gravação/execução (rwx) de definição de acesso, mas o NFSv4.x fornece uma série de outros controles de acesso granulares como uma melhoria em relação aos bits do modo NFSv3.

Há 13 permissões que podem ser definidas para usuários e 14 permissões que podem ser definidas para grupos.

Carta de permissão	Permissão concedida
r	Ler dados/listar ficheiros e pastas
w	Escrever dados/criar ficheiros e pastas
a	Acrescentar dados/criar subdiretórios
x	Executar arquivos/diretórios de travessia
d	Excluir arquivos/diretórios
D	Excluir subdiretórios (somente diretórios)
t	Ler atributos (GETATTR)
T	Atributos de escrita (SETATTR/chmod)
n	Ler atributos nomeados
N	Escrever atributos nomeados
c	Ler ACLs
C	Escrever ACLs
o	Escrever proprietário (chown)
S	E/S Síncrona

Quando as permissões de acesso são definidas, uma entidade de usuário ou grupo adere aos direitos atribuídos.

Exemplos de permissão NFSv4.x

Os exemplos a seguir mostram como diferentes permissões funcionam com diferentes cenários de configuração.

Utilizador com acesso de leitura (apenas r)

Com o acesso somente leitura, um usuário pode ler atributos e dados, mas qualquer acesso de gravação (dados, atributos, proprietário) é negado.

A::user1@CONTOSO.COM:r

sh-4.2$ ls -la
total 12
drwxr-xr-x 3 root root 4096 Jul 12 12:41 .
drwxr-xr-x 3 root root 4096 Jul 12 12:09 ..
-rw-r--r-- 1 root root    0 Jul 12 12:41 file
drwxr-xr-x 2 root root 4096 Jul 12 12:31 subdir
sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ chown user1 file
chown: changing ownership of ‘file’: Operation not permitted
sh-4.2$ nfs4_setfacl -e /mnt/acl-dir/inherit-dir
Failed setxattr operation: Permission denied
sh-4.2$ rm file
rm: remove write-protected regular empty file ‘file’? y
rm: can't remove ‘file’: Permission denied
sh-4.2$ cat file
Test text

Usuário com acesso de leitura (r) e atributos de gravação (T)

Neste exemplo, as permissões no arquivo podem ser alteradas devido à permissão de atributos de gravação (T), mas nenhum arquivo pode ser criado, pois apenas o acesso de leitura é permitido. Essa configuração ilustra o tipo de controles granulares que as ACLs NFSv4.x podem fornecer.

A::user1@CONTOSO.COM:rT

sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ ls -la
total 60
drwxr-xr-x  3 root     root    4096 Jul 12 16:23 .
drwxr-xr-x 19 root     root   49152 Jul 11 09:56 ..
-rw-r--r--  1 root     root      10 Jul 12 16:22 file
drwxr-xr-x  3 root     root    4096 Jul 12 12:41 inherit-dir
-rw-r--r--  1 user1    group1     0 Jul 12 16:23 user1-file
sh-4.2$ chmod 777 user1-file
sh-4.2$ ls -la
total 60
drwxr-xr-x  3 root     root    4096 Jul 12 16:41 .
drwxr-xr-x 19 root     root   49152 Jul 11 09:56 ..
drwxr-xr-x  3 root     root    4096 Jul 12 12:41 inherit-dir
-rwxrwxrwx  1 user1    group1     0 Jul 12 16:23 user1-file
sh-4.2$ rm user1-file
rm: can't remove ‘user1-file’: Permission denied

Convertendo bits de modo em permissões de ACL NFSv4.x

Quando um chmod é executado um objeto com ACLs NFSv4.x atribuídas, uma série de ACLs do sistema são atualizadas com novas permissões. Por exemplo, se as permissões estiverem definidas como 755, os arquivos ACL do sistema serão atualizados. A tabela a seguir mostra o que cada valor numérico em um bit de modo se traduz em permissões de ACL NFSv4.

Consulte Permissões NFSv4.x para obter uma tabela que descreve todas as permissões.

Modo de bit numérico	Permissões NFSv4.x correspondentes
1 – Executar (x)	Executar, ler atributos, ler ACLs, sincronizar E/S (xtcy)
2 – Escrever (W)	Gravar, acrescentar dados, ler atributos, escrever atributos, escrever atributos nomeados, ler ACLs, sincronizar E/S (watTNcy)
3 – Gravação/execução (wx)	Gravar, acrescentar dados, executar, ler atributos, escrever atributos, escrever atributos nomeados, ler ACLs, sincronizar E/S (waxtTNcy)
4 – Ler (R)	Ler, ler atributos, ler atributos nomeados, ler ACLs, sincronizar E/S (rtncy)
5 – Ler/Executar (Rx)	Ler, executar, ler atributos, ler atributos nomeados, ler ACLs, sincronizar E/S (rxtncy)
6 – Leitura/Escrita (RW)	Ler, escrever, acrescentar dados, ler atributos, escrever atributos, ler atributos nomeados, escrever atributos nomeados, ler ACLs, sincronizar E/S (rwatTnNcy)
7 – Leitura/Gravação/Execução (RWX)	Controle total/todas as permissões

Como as ACLs NFSv4.x funcionam com os Arquivos NetApp do Azure

Os Arquivos NetApp do Azure dão suporte a ACLs NFSv4.x nativamente quando um volume tem NFSv4.1 habilitado para acesso. Não há nada a ser habilitado no volume para suporte a ACL, mas para que as ACLs NFSv4.1 funcionem melhor, um servidor LDAP com usuários e grupos UNIX é necessário para garantir que os Arquivos NetApp do Azure sejam capazes de resolver as entidades definidas nas ACLs com segurança. Os usuários locais podem ser usados com ACLs NFSv4.x, mas eles não fornecem o mesmo nível de segurança que as ACLs usadas com um servidor LDAP.

Há considerações a ter em mente com a funcionalidade ACL nos Arquivos NetApp do Azure.

Herança do LCA

Nos Arquivos NetApp do Azure, os sinalizadores de herança de ACL podem ser usados para simplificar o gerenciamento de ACL com ACLs NFSv4.x. Quando um sinalizador de herança é definido, as ACLs em um diretório pai podem se propagar para subdiretórios e arquivos sem mais interação. Os Arquivos NetApp do Azure implementam comportamentos de herança de ACL padrão de acordo com RFC-7530.

Negar ACEs

Negar ACEs nos Arquivos NetApp do Azure são usados para restringir explicitamente o acesso de um usuário ou grupo a um arquivo ou pasta. Um subconjunto de permissões pode ser definido para fornecer controles granulares sobre a ACE de negação. Estes operam nos métodos padrão mencionados no RFC-7530.

Preservação do LCA

Quando um chmod é executado em um arquivo ou pasta nos Arquivos NetApp do Azure, todas as ACEs existentes são preservadas na ACL diferente das ACEs do sistema (OWNER@, GROUP@, EVERYONE@). Essas permissões ACE são modificadas conforme definido pelos bits de modo numérico definidos pelo comando chmod. Apenas as ACEs que são modificadas ou removidas manualmente através do nfs4_setfacl comando podem ser alteradas.

Comportamentos da ACL NFSv4.x em ambientes de protocolo duplo

Protocolo duplo refere-se ao uso de SMB e NFS no mesmo volume de Arquivos NetApp do Azure. Os controles de acesso de protocolo duplo são determinados pelo estilo de segurança que o volume está usando, mas o mapeamento de nome de usuário garante que os usuários do Windows e os usuários do UNIX mapeados com êxito um para o outro tenham as mesmas permissões de acesso aos dados.

Quando as ACLs NFSv4.x estão em uso em volumes de estilo de segurança UNIX, os comportamentos a seguir podem ser observados ao usar volumes de protocolo duplo e acessar dados de clientes SMB.

Os nomes de usuário do Windows precisam ser mapeados corretamente para nomes de usuário UNIX para uma resolução de controle de acesso adequada.
Em volumes de estilo de segurança UNIX (onde as ACLs NFSv4.x seriam aplicadas), se nenhum usuário UNIX válido existir no servidor LDAP para um usuário do Windows ser mapeado, um usuário UNIX padrão chamado pcuser (com uid numérico 65534) será usado para mapeamento.
Os arquivos escritos com usuários do Windows sem mapeamento de usuário UNIX válido são exibidos como pertencentes ao ID numérico 65534, que corresponde a nomes de usuário "nfsnobody" ou "nobody" em clientes Linux de montagens NFS. Isso é diferente do ID numérico 99, que normalmente é visto com problemas de domínio de ID NFSv4.x. Para verificar a ID numérica em uso, use o ls -lan comando.
Arquivos com proprietários incorretos não fornecem resultados esperados de bits de modo UNIX ou de ACLs NFSv4.x.
As ACLs NFSv4.x são gerenciadas a partir de clientes NFS. Os clientes SMB não podem visualizar nem gerenciar ACLs NFSv4.x.

Impacto do Umask com ACLs NFSv4.x

As ACLs NFSv4 fornecem a capacidade de oferecer herança de ACL. Herança de ACL significa que arquivos ou pastas criados abaixo de objetos com ACLs NFSv4 definidas podem herdar as ACLs com base na configuração do sinalizador de herança de ACL.

Umask é usado para controlar o nível de permissão no qual os arquivos e pastas são criados em um diretório. Por padrão, os Arquivos NetApp do Azure permitem que o umask substitua ACLs herdadas, o que é um comportamento esperado de acordo com a RFC-7530.

Para obter mais informações, consulte umask.

Comportamento Chmod/chown com ACLs NFSv4.x

Nos Arquivos NetApp do Azure, você pode usar os comandos change ownership (chown) e change mode bit (chmod) para gerenciar permissões de arquivo e diretório em NFSv3 e NFSv4.x.

Ao usar ACLs NFSv4.x, os controles mais granulares aplicados a arquivos e pastas diminuem a necessidade de comandos chmod. O Chown ainda tem um lugar, pois as ACLs NFSv4.x não atribuem propriedade.

Quando o chmod é executado nos Arquivos NetApp do Azure em arquivos e pastas com ACLs NFSv4.x aplicadas, os bits de modo são alterados no objeto. Além disso, um conjunto de ACEs do sistema são modificadas para refletir esses bits de modo. Se as ACEs do sistema forem removidas, os bits de modo serão limpos. Exemplos e uma descrição mais completa podem ser encontrados na seção sobre ACEs do sistema abaixo.

Quando chown é executado em Arquivos NetApp do Azure, o proprietário atribuído pode ser modificado. A propriedade do arquivo não é tão crítica ao usar ACLs NFSv4.x quanto ao usar bits de modo, pois as ACLs podem ser usadas para controlar permissões de maneiras que os conceitos básicos de proprietário/grupo/todos não poderiam. Chown no Azure NetApp Files só pode ser executado como root (como root ou usando sudo), uma vez que os controles de exportação são configurados para permitir apenas que root faça alterações de propriedade. Como isso é controlado por uma regra de política de exportação padrão nos Arquivos NetApp do Azure, as entradas de ACL NFSv4.x que permitem modificações de propriedade não se aplicam.

# su user1
# chown user1 testdir
chown: changing ownership of ‘testdir’: Operation not permitted
# sudo chown user1 testdir
# ls -la | grep testdir
-rw-r--r--  1 user1    root     0 Jul 12 16:23 testdir

A regra de política de exportação no volume pode ser modificada para alterar esse comportamento. No menu Política de exportação do volume, modifique o modo Chown para "irrestrito".

Uma vez modificada, a propriedade pode ser alterada por usuários que não sejam root, se eles tiverem direitos de acesso apropriados. Isso requer a permissão "Take Ownership" NFSv4.x ACL (designada pela letra "o"). A propriedade também pode ser alterada se o usuário que está mudando de propriedade for atualmente proprietário do arquivo ou pasta.

A::user1@contoso.com:rwatTnNcCy  << no ownership flag (o)

user1@ubuntu:/mnt/testdir$ chown user1 newfile3
chown: changing ownership of 'newfile3': Permission denied

A::user1@contoso.com:rwatTnNcCoy  << with ownership flag (o)

user1@ubuntu:/mnt/testdir$ chown user1 newfile3
user1@ubuntu:/mnt/testdir$ ls -la
total 8
drwxrwxrwx 2 user2 root       4096 Jul 14 16:31 .
drwxrwxrwx 5 root  root       4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1 root          0 Jul 14 15:45 newfile
-rw-r--r-- 1 root  root          0 Jul 14 15:52 newfile2
-rw-r--r-- 1 user1 4294967294    0 Jul 14 16:31 newfile3

ACEs do sistema

Em cada ACL, há uma série de ACEs de sistema: OWNER@, GROUP@, EVERYONE@. Por exemplo:

A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

Essas ACEs correspondem às permissões de bits do modo clássico que você veria no NFSv3 e estão diretamente associadas a essas permissões. Quando um chmod é executado em um objeto, essas ACLs do sistema mudam para refletir essas permissões.

# nfs4_getfacl user1-file

# file: user1-file
A::user1@CONTOSO.COM:rT
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

# chmod 755 user1-file

# nfs4_getfacl user1-file

# file: user1-file
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rxtncy

Se essas ACEs do sistema forem removidas, a visualização de permissão será alterada de modo que os bits de modo normal (rwx) apareçam como traços.

# nfs4_setfacl -x A::OWNER@:rwaxtTnNcCy user1-file
# nfs4_setfacl -x A:g:GROUP@:rxtncy user1-file
# nfs4_setfacl -x A::EVERYONE@:rxtncy user1-file
# ls -la | grep user1-file
----------  1 user1 group1     0 Jul 12 16:23 user1-file

Remover ACEs do sistema é uma maneira de proteger ainda mais arquivos e pastas, pois apenas os principais usuários e grupos na ACL (e raiz) são capazes de acessar o objeto. A remoção de ACEs do sistema pode quebrar aplicativos que dependem de visualizações de bits de modo para funcionalidade.

Comportamento do usuário raiz com ACLs NFSv4.x

O acesso root com ACLs NFSv4.x não pode ser limitado, a menos que o root seja esmagado. A eliminação de raiz é quando uma regra de política de exportação é configurada, onde a raiz é mapeada para um usuário anônimo para limitar o acesso. O acesso raiz pode ser configurado a partir do menu Política de exportação de um volume, alterando a regra de política de Acesso raiz para desativado.

Para configurar o esmagamento de raiz, navegue até o menu Exportar política no volume e altere "Acesso raiz" para "desativado" para a regra de política.

O efeito de desativar squashes raiz de acesso raiz para usuário nfsnobody:65534anônimo . O acesso root não pode então alterar a propriedade.

root@ubuntu:/mnt/testdir# touch newfile3
root@ubuntu:/mnt/testdir# ls -la
total 8
drwxrwxrwx 2 user2  root       4096 Jul 14 16:31 .
drwxrwxrwx 5 root   root       4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1  root          0 Jul 14 15:45 newfile
-rw-r--r-- 1 root   root          0 Jul 14 15:52 newfile2
-rw-r--r-- 1 nobody 4294967294    0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# ls -lan
total 8
drwxrwxrwx 2  1002          0 4096 Jul 14 16:31 .
drwxrwxrwx 5     0          0 4096 Jul 13 13:46 ..
-rw-r--r-- 1  1001          0    0 Jul 14 15:45 newfile
-rw-r--r-- 1     0          0    0 Jul 14 15:52 newfile2
-rw-r--r-- 1 65534 4294967294    0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# chown root newfile3
chown: changing ownership of 'newfile3': Operation not permitted

Como alternativa, em ambientes de protocolo duplo, as ACLs NTFS podem ser usadas para limitar granularmente o acesso raiz.

Partilhar via