Entender listas de controle de acesso NFSv4.x no Azure NetApp Files

O protocolo NFSv4.x pode fornecer controle de acesso na forma de ACLs (listas de controle de acesso), que são conceitualmente semelhantes às ACLs usadas em SMB por meio de permissões do Windows NTFS. Uma ACL NFSv4.x consiste em ACEs (Entradas de Controle de Acesso) 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), Negação (D), Auditoria (U), Alarme (L). O Azure NetApp Files dá suporte aos tipos de ACL de Acesso, Negação e Auditoria, mas as ACLs de Auditoria, embora possam ser definidas, não produzem logs de auditoria no momento.
• Flags – Adiciona contexto extra para uma ACL. Há três tipos de sinalizadores ACE: grupo, herança e administrativo. Para obter mais informações sobre sinalizadores, consulte sinalizadores ACE NFSv4.x.
• Entidade de Segurança – Define o usuário ou grupo que está recebendo a ACL. Uma entidade de segurança 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 de grupo NFSv4.x.
• Permissões – Onde o nível de acesso da entidade de segurança é definido. Cada permissão é designada como uma única letra (por exemplo, leitura obtém “r”, gravação obtém “w” e assim por diante). O acesso completo incorporaria cada letra de permissão disponível. Para obter mais informações, consulte Permissões de NFSv4.x.

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

Sinalizadores ACE NFSv4.x

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

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

Acessar e negar sinalizadores

Os sinalizadores de Acesso (A) e Negação (D) são usados para controlar os tipos 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 um ACE de acesso seja definido que permita que essa entidade acesse o objeto. As ACEs de negação sempre substituem 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. As ACEs de negação podem criar complicações desnecessárias no gerenciamento de 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, arquivos e/ou diretórios herdam as ACLs da pasta pai. Sinalizadores de herança só podem ser aplicados a diretórios, portanto, quando um subdiretório é criado, ele herda o sinalizador. 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.

Exemplos de ACL NFSv4.x

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

• somente herança de diretório (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 um 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, 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 tem apenas um sinalizador de herança de arquivo. Como resultado, somente 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-propagate” (n) é definido em uma ACL, os sinalizadores são desmarcados em criações de diretórios subsequentes abaixo do pai. No exemplo a seguir, user2 tem o sinalizador n definido. Como resultado, o subdiretório limpa os sinalizadores herdados para essa entidade de segurança e os objetos criados abaixo desse subdiretório não herdam o 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 herdados são uma maneira de gerenciar mais facilmente suas ACLs NFSv4.x, poupando você de definir explicitamente uma ACL sempre que precisar de uma.

Sinalizadores administrativos

Sinalizadores administrativos em ACLs NFSv4.x são sinalizadores especiais que são usados apenas com tipos de ACL de Auditoria e Alarme. Esses sinalizadores definem êxito (S) ou falha (F) nas tentativas de acesso para que as ações sejam executadas.

O Azure NetApp Files dá suporte à configuração de sinalizadores administrativos para ACEs de Auditoria, no entanto, as ACEs não funcionam. Além disso, não há suporte para ACEs de Alarme no Azure NetApp Files.

Entidades de usuário e grupo do NFSv4.x

Com ACLs NFSv4.x, entidades de usuário e de grupo definem os objetos específicos aos quais um ACE deve se aplicar. As entidades de segurança geralmente seguem um formato de name@ID-DOMAIN-STRING.COM. A parte de “nome” de uma entidade de segurança pode ser um usuário ou grupo, mas esse usuário ou grupo deve ser resolvido no Azure NetApp Files por meio da conexão de servidor LDAP ao especificar o domínio de ID NFSv4.x. Se o name@domain não puder ser resolvido pelo Azure NetApp Files, 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 no Azure NetApp Files se um nome pode ser resolvido usando a lista de IDs do grupo LDAP. Navegue até Suporte + Solução de Problemas e, em seguida, Lista de IDs de Grupo LDAP.

Acesso de usuário local e grupo por meio de ACLs NFSv4.x

Usuários e grupos locais também poderão ser usados em uma ACL NFSv4.x se apenas a ID numérica for especificada na ACL. Os nomes de usuário ou as IDs numéricas com uma ID de domínio especificada 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 um usuário local ou ACL grupo é 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 o Azure NetApp Files. 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 por meio de uma captura de pacotes, conforme visto abaixo.

Restrições:

• O uso de usuários e grupos locais para ACLs significa que todos os clientes que acessam os arquivos/pastas precisam ter IDs de usuário e grupo correspondentes.
• Ao usar uma ID numérica para uma ACL, o Azure NetApp Files confia 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 ele afirma ser membro. Um usuário ou grupo numérico pode ser falsificado se um ator inválido conhece a ID numérica e pode 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 de grupo estendido sejam usados.
• As cadeias de caracteres de nome LDAP e nome completo@nome de domínio 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 ao usuário menos provável.

Domínio de ID NFSv4.x

O domínio de ID é um componente importante da entidade de segurança, em que um domínio de ID deve corresponder no cliente e no Azure NetApp Files para nomes de usuário e grupo (especificamente, raiz) para aparecer corretamente em propriedades de arquivo/pasta.

O Azure NetApp Files usa como padrão o domínio de ID NFSv4.x para as configurações de domínio DNS para o volume. Os clientes NFS também tem 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 do Azure NetApp Files, ocorrerá uma incompatibilidade. Ao listar permissões de arquivo com comandos como ls, os usuários/grupos aparecem como “ninguém".

Quando ocorre uma incompatibilidade de domínio entre o cliente NFS e o Azure NetApp Files, verifique se há erros semelhantes aos dos logs do cliente:

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 de “Domínio” do arquivo /etc/idmapd.conf. Por exemplo: Domain = CONTOSO.COM.

O Azure NetApp Files também permite que você altere o domínio de ID NFSv4.1. Para obter mais detalhes, consulte Instruções: Configuração de Domínio de ID do NFSv4.1 para o Azure NetApp Files.

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 só permitem 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 que podem ser definidas para grupos.

Quando as permissões de acesso forem definidas, um usuário ou entidade de segurança do grupo adere a esses 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.

Usuário com acesso de leitura (somente 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 somente 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

Tradução de bits de modo em permissões de ACL NFSv4.x

Quando um chmod é executado em 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 forem definidas como 755, os arquivos ACL do sistema serão atualizados. A tabela a seguir mostra em que cada valor numérico em um bit de modo é traduzido nas permissões de ACL NFSv4.

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

Como as ACLs NFSv4.x funcionam com o Azure NetApp Files

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

É necessário ter em mente algumas considerações da funcionalidade de ACL no Azure NetApp Files.

Herança de ACL

No Azure NetApp Files, 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 interação adicional. O Azure NetApp Files implementa comportamentos padrão de herança de ACL de acordo com RFC-7530.

Negar ACEs

Negar ACEs no Azure NetApp Files é usado 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 o ACE de negação. Eles operam nos métodos padrão mencionados em RFC-7530.

Preservação da ACL

Quando um chmod é executado em um arquivo ou pasta no Azure NetApp Files, todos os ACEs existentes são preservados na ACL diferente dos 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. Somente ACEs que são modificadas ou removidas manualmente por meio do comando nfs4_setfacl podem ser alteradas.

Comportamentos de ACL NFSv4.x em ambientes de protocolo duplo

O protocolo duplo refere-se ao uso de SMB e NFS no mesmo volume do Azure NetApp Files. 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 UNIX que são mapeados com êxito uns para os outros 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 a resolução adequada do controle de acesso.
• Em volumes de estilo de segurança UNIX (em que as ACLs NFSv4.x seriam aplicadas), se nenhum usuário UNIX válido existir no servidor LDAP para um usuário do Windows para o qual mapear, um usuário UNIX padrão chamado pcuser (com uid numérica 65534) será usado para mapeamento.
• Arquivos gravados com usuários do Windows sem nenhum mapeamento de usuário UNIX válido são exibidos de propriedade da ID numérica 65534, que corresponde a nomes de usuário “nfsnobody” ou “nobody” em clientes Linux de montagens NFS. Isso é diferente da ID numérica 99, que normalmente é vista com problemas de domínio de ID NFSv4.x. Para verificar a ID numérica em uso, use o comando ls -lan.
• Arquivos com proprietários incorretos não fornecem resultados esperados de bits do modo UNIX ou de ACLs NFSv4.x.
• As ACLs NFSv4.x são gerenciadas de clientes NFS. Os clientes SMB não podem exibir nem gerenciar ACLs NFSv4.x.

Impacto da Umask com ACLs NFSv4.x

ACLs NFSv4 fornecem a capacidade de oferecer herança de ACL. A herança de ACL significa que arquivos ou pastas criadas 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 arquivos e pastas são criados em um diretório. Por padrão, o Azure NetApp Files permite que umask substitua ACLs herdadas, o que é o comportamento esperado de acordo com RFC-7530.

Para mais informações, consulte umask.

Comportamento chmod/chown com ACLs NFSv4.x

No Azure NetApp Files, você pode usar comandos de alteração de propriedade (chown) e bit de modo de alteração (chmod) para gerenciar permissões de arquivo e diretório no NFSv3 e NFSv4.x.

Ao usar ACLs NFSv4.x, os controles mais granulares aplicados a arquivos e pastas reduzem a necessidade de comandos chmod. Chown ainda tem seu lugar, já que as ACLs NFSv4.x não atribuem a propriedade.

Quando o chmod é executado no Azure NetApp Files 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 modificados para refletir esses bits de modo. Se os ACEs do sistema forem removidos, os bits do modo serão desmarcados. Exemplos e uma descrição mais completa podem ser encontrados na seção nos ACEs do sistema abaixo.

Quando o chown é executado no Azure NetApp Files, o proprietário atribuído pode ser modificado. A propriedade de arquivo não é tão crítica ao usar ACLs NFSv4.x como 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 puderam. O Chown no Azure NetApp Files só pode ser executado como raiz (como raiz ou usando sudo), já que os controles de exportação são configurados para permitir apenas que a raiz faça alterações de propriedade. Como isso é controlado por uma regra de política de exportação padrão no Azure NetApp Files, 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 Exportar política para o volume, modifique o modo Chown para "irrestrito".

Após modificar, a propriedade poderá ser alterada por usuários que não sejam raiz se tiverem direitos de acesso apropriados. Isso requer a permissão de ACL NFSv4.x “Take Ownership” (designada pela letra “o”). A propriedade também pode ser alterada se o usuário que altera a propriedade atualmente possui o arquivo ou a 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 do sistema: OWNER@, GROUP@, EVERYONE@. Por exemplo:

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

Esses ACEs correspondem às permissões de bits de modo clássico que você veria no NFSv3 e estão diretamente associados a essas permissões. Quando um chmod é executado em um objeto, essas ACLs do sistema são alteradas 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 esses ACEs do sistema forem removidos, a exibição de permissão será alterada de modo que os bits do 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

A remoção de ACEs do sistema é uma maneira de proteger ainda mais arquivos e pastas, pois somente o usuário e as entidades de segurança de grupo na ACL (e raiz) são capazes de acessar o objeto. A remoção de ACEs do sistema pode interromper aplicativos que dependem de modos de exibição de bits para funcionalidade.

Comportamento do usuário raiz com ACLs NFSv4.x

O acesso raiz com ACLs NFSv4.x não pode ser limitado, a menos que a raiz seja combinada por squash. A combinação por squash da raiz é onde uma regra de política de exportação é configurada em que a raiz é mapeada para um usuário anônimo para limitar o acesso. O acesso raiz pode ser configurado no menu Exportar política de um volume alterando a regra de política do Acesso raiz para desativada.

Para configurar a combinação por squash da 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 desabilitar a combinação por squash da raiz de acesso à nfsnobody:65534 de usuário anônimo. Em seguida, o acesso raiz não pode 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 do NTFS podem ser usadas para limitar granularmente o acesso raiz.

Próximas etapas

• Configurar clientes NFS
• Configurar listas de controle de acesso em volumes NFSv4.1