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

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 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), 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 marcadores ACE: grupo, herança e administrativo. Para obter mais informações sobre sinalizadores, consulte Sinalizadores NFSv4.x ACE.
• Principal – define o usuário ou grupo ao qual está sendo atribuída a ACL. Um principal numa ACL NFSv4.x usa o formato de name@ID-DOMAIN-STRING.COM. Para obter informações mais detalhadas sobre os principais, consulte principais de utilizador e grupo do NFSv4.x.
• Permissões – como o nível de acesso para o principal é definido. As permissões são designadas por uma única letra. Por exemplo, "r" confere permissões de leitura, "w" confere permissões de escrita. 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.

Indicadores ACE NFSv4.x

Um marcador ACE ajuda a fornecer mais informações sobre um ACE em uma ACL. Por exemplo, ao adicionar uma ACE de grupo a uma ACL, é necessário usar um sinalizador de grupo para indicar que a entidade é um grupo e não um utilizador. É possível em ambientes Linux ter um nome de utilizador e um nome de grupo que sejam idênticos, pelo que o sinalizador garante que um ACE seja respeitado, e o servidor NFS precisa saber que tipo de entidade está a ser definida.

Outros sinalizadores podem ser usados para controlar ACEs, como sinalizadores de herança e sinalizadores de administração.

Sinalizadores de acesso e negação

Os marcadores de acesso (A) e negação (D) são utilizados 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 um principal. Uma ACE de negação proíbe explicitamente uma entidade de segurança de acessar um arquivo ou pasta, mesmo que exista uma ACE de acesso que permitiria a essa entidade aceder ao objeto. Os ACEs de negação prevalecem sempre sobre os 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.

Flags de herança

Os indicadores de herança controlam como as ACLs se comportam em ficheiros criados sob um diretório pai com o indicador de herança definido. Quando um sinalizador de herança é ativado, 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 dentro de um diretório pai com um sinalizador de herança herdam as ACLs, mas não os próprios 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 herança de diretório
• (fi) - herdar apenas ficheiros
• (fdi) - herdam arquivos e diretórios

# 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 uma ACL que herda apenas do diretório. Em um subdiretório criado abaixo do diretório pai, a ACL é herdada, mas em um arquivo abaixo do diretório 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 indicador de herança de ficheiro 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 indicador 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-propagate" (n) é definido numa ACL, os sinalizadores são limpos nas criações de diretório subsequentes abaixo do diretório pai. No exemplo a seguir, user2 tem a n bandeira ativada. Como resultado, o subdiretório limpa os sinalizadores de herança para essa entidade e os objetos criados abaixo desse subdiretório não irão herdar 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 as suas ACLs NFSv4.x, poupando-te de definir explicitamente uma ACL sempre que precisares de uma.

Bandeiras administrativas

As bandeiras administrativas nas ACLs NFSv4.x são bandeiras especiais que são usadas 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.

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

Os Arquivos NetApp do Azure dão suporte apenas à configuração de sinalizadores administrativos para ACEs de Auditoria. As ACEs de auditoria são necessárias para logs de acesso a ficheiros. As ACEs de alarme não são suportadas nos NetApp Files no Azure.

Principais de utilizador 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 escolares normalmente 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 utilizador 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@domínio completas são altamente recomendadas ao usar ACLs NFSv4.x para maior facilidade de gestão 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 do principal, onde um domínio de ID deve corresponder tanto no cliente quanto dentro dos Arquivos NetApp do Azure para que os nomes de usuários e grupos (especificamente, "root") apareçam corretamente nas propriedades de posse dos arquivos/pastas.

Os Arquivos NetApp do Azure definem por predefinição o domínio de ID NFSv4.x para as definições de domínio DNS do 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 utilizando a configuração "Domain" do ficheiro /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 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 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.

Quando as permissões de acesso são definidas, um utilizador ou grupo respeita os 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.

Utilizador com acesso de leitura (apenas r)

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

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 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 estiverem definidas como 755, os arquivos ACL do sistema serão atualizados. A tabela a seguir mostra o que cada valor numérico nos bits de modo representa em permissões de ACL NFSv4.

Consulte Permissões NFSv4.x para obter uma tabela que descreve 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 ativado no volume para suporte a ACL, mas para que as ACLs NFSv4.1 funcionem da melhor forma, é necessário um servidor LDAP com utilizadores e grupos UNIX para garantir que o Azure NetApp Files consiga resolver, com segurança, as entidades definidas nas ACLs. 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 relativamente à funcionalidade ACL dos Azure NetApp Files.

Herança da ACL

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 ficheiros do NetApp do Azure implementam os comportamentos padrão de herança de ACL de acordo com o 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@). As permissões ACE são alteradas conforme os 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 não existir nenhum utilizador UNIX válido no servidor LDAP para correspondência com um utilizador do Windows, um utilizador UNIX padrão chamado pcuser (com uid numérico 65534) será utilizado para essa correspondência.
• Os ficheiros criados por utilizadores do Windows sem mapeamento de utilizador UNIX válido são exibidos como pertencendo ao ID numérico 65534, que corresponde aos nomes de utilizador "nfsnobody" ou "nobody" em clientes Linux através de montagens NFS. Isso é diferente do ID numérico 99, que normalmente é associado a problemas de domínio de ID NFSv4.x. Para verificar a ID numérica em uso, use o ls -lan comando.
• Ficheiros com proprietários incorretos não produzem os resultados esperados dos bits de modo do UNIX ou das ACLs do 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 nas ACLs do 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 umask substitua ACLs herdadas, o que é um comportamento esperado de acordo com RFC-7530.

Para obter mais informações, consulte umask.

Comportamento de Chmod/chown com ACLs NFSv4.x

Nos ficheiros NetApp do Azure, pode utilizar os comandos change ownership (chown) e change mode bit (chmod) para gerir permissões de ficheiros e diretórios 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 comando chmod é executado nos Arquivos NetApp do Azure em ficheiros 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 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 o chown é executado nos NetApp Files do Azure, o proprietário atribuído pode ser modificado. A propriedade do ficheiro não é tão crítica ao recorrer a ACLs NFSv4.x quanto ao usar bits de modo, já que as ACLs podem ser utilizadas para controlar permissões de maneiras que os conceitos básicos de dono/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 "sem restrições".

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 exibição de permissões será alterada de forma 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 comprometer aplicações que dependem de visualizações de bits de modo para funcionalidade.

Comportamento do utilizador root com ACLs NFSv4.x

O acesso root com ACLs NFSv4.x não pode ser limitado, a menos que root seja suprimido. 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 root pode ser configurado a partir do menu Política de Exportação de um volume, alterando a regra de política de Acesso root para desativado.

Para configurar o root squashing, navegue até o menu Política de Exportação no volume e altere "Acesso raiz" para "desativado" na regra de política.

O efeito de desativar a compressão de root access para o usuário anônimo nfsnobody:65534. 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.

Próximos passos

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