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 usa 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. 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 que está recebendo a ACL. Um principal em uma ACL NFSv4.x usa o formato de name@ID-DOMAIN-STRING.COM. Para obter informações mais detalhadas sobre os principais, veja Principais de usuário e grupo do NFSv4.x.
• Permissões: como o nível de acesso da entidade de segurança é definido. As permissões são designadas por uma única letra. Por exemplo, "r" confere permissões de leitura, "w" confere permissões de gravação. 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.

Bandeiras ACE do 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 o principal é 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; em seguida, o servidor NFS precisa saber que tipo de principal está sendo definido.

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

Sinalizadores de acesso e negação

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 um principal. 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. ACEs de negação sempre anulam 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 indicador de herança é definido, os arquivos e/ou diretórios herdam as ACLs da pasta mãe. 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:

• (di): somente directory inherit
• (fi): somente file inherit
• (fdi) – tanto o file inherit quanto directory inherit

# 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 limpos 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 de herança para esse principal e os objetos criados abaixo desse subdiretório não herdam o ACE deuser2.

#  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

Os sinalizadores administrativos em ACLs do NFSv4.x são sinalizadores especiais usados ​​somente com os 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.

Esta ACL de auditoria é um exemplo disso, onde user1 é auditado para tentativas de acesso com falha para qualquer nível de permissão: U:F:user1@contoso.com:rwatTnNcCy.

O Azure NetApp Files dá suporte apenas à configuração de sinalizadores administrativos para ACEs de auditoria. ACEs de auditoria são necessários para logs de acesso a arquivos. Os ACEs de alarme não são suportados no Azure NetApp Files.

Principais usuários e grupos 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 "nome" de uma entidade de segurança pode ser um usuário ou grupo, mas esse usuário ou grupo deve ser resolvível no Azure NetApp Files por meio da conexão do servidor LDAP ao especificar o domínio de ID do NFSv4.x. Se o name@domain não for resolvível 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ários locais e grupos via 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 uma ACL de usuário ou de 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 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 sequências de caracteres LDAP e nome completo@nome de domínio são altamente recomendadas ao usar ACLs NFSv4.x para melhor 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 define como padrão o domínio de ID NFSv4.x para as configurações de domínio DNS do 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 opção "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 permitem apenas níveis de definição de acesso de leitura/gravação/execução (rwx), 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 são definidas, um usuário ou membro de grupo cumpre esses direitos atribuídos.

Exemplos de permissões 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 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

Traduzindo bits de modo em permissões de ACL do 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 o que cada valor numérico em um bit de modo representa nas permissões da ACL do 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 é necessário habilitar nada no volume para suporte à ACL, mas para que as ACLs NFSv4.1 funcionem melhor, é necessário um servidor LDAP com usuários e grupos UNIX para garantir que o Azure NetApp Files seja capaz de resolver as entidades principais definidas nas ACLs de forma segura. 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, 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 a 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 (onde ACLs NFSv4.x seriam aplicadas), se não houver nenhum usuário UNIX válido no servidor LDAP para um usuário do Windows mapear, um usuário UNIX padrão chamado pcuser (com uid numérico 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 do ID numérico 99, que normalmente é visto em problemas de domínio de ID do NFSv4.x. Para verificar a ID numérica em uso, use o comando ls -lan.
• Arquivos com proprietários incorretos não fornecem os resultados esperados dos bits do modo UNIX ou das ACLs do 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 do Umask com ACLs NFSv4.x

As ACLs do NFSv4 oferecem 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 os comandos alterar propriedade (chown) e alterar bit de modo (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 um lugar, já que as ACLs do NFSv4.x não atribuem 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 é modificado para refletir esses bits de modo. Se os ACEs do sistema forem removidos, os bits de modo serão limpos. Exemplos e uma descrição mais completa podem ser encontrados na seção de ACEs do sistema abaixo.

Quando o chown é executado no Azure NetApp Files, o proprietário atribuído pode ser modificado. A propriedade do arquivo não é tão crítica ao usar ACLs do 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 conseguiriam. O Chown no Azure NetApp Files só pode ser executado como root (como root ou usando sudo), pois os controles de exportação são configurados para permitir que somente o root 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 Política de exportação do volume, modifique o Modo Chown para "irrestrito."

Uma vez modificada, a propriedade pode ser alterada por outros usuários além do root, se eles tiverem direitos de acesso apropriados. É necessário ter a permissão "Take Ownership" nas ACL NFSv4.x (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

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 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 visualizações de bits de modo para funcionalidade.

Comportamento do usuário root com ACLs NFSv4.x

O acesso root com ACLs NFSv4.x não pode ser limitado, a menos que root seja compactado. O root squashing ocorre quando uma regra de política de exportação é configurada, na qual o root é mapeado para um usuário anônimo para limitar o acesso. O acesso raiz pode ser configurado no menu Política de Exportação de um volume pela alteração da regra de política Acesso raiz para desligado.

Para configurar o root squashing, navegue até o menu Exportar política no volume e altere "Acesso raiz" para "desativar" 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. O acesso root não permite 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