As permissões de bits de modo abrangem apenas o proprietário, o grupo e todos os outros na semântica, o que significa que não há controles granulares de acesso de usuário para o NFSv3 básico. O Google Cloud NetApp Volumes não oferece suporte a ACLs POSIX nem a atributos estendidos (como chattr), portanto, ACLs granulares só são possíveis nos seguintes cenários com NFSv3:

Ambos os métodos exigem uma conexão LDAP para gerenciamento de identidade UNIX e informações válidas de usuário e grupo UNIX preenchidas (consulte a seção"LDAP" ) e estão disponíveis somente com instâncias do NetApp Volumes-Performance. Para usar volumes de estilo de segurança NTFS com NFS, você deve usar protocolo duplo (SMB e NFSv3) ou protocolo duplo (SMB e NFSv4.1), mesmo que nenhuma conexão SMB seja feita. Para usar ACLs NFSv4.1 com montagens NFSv3, você deve selecionar Both (NFSv3/NFSv4.1) como o tipo de protocolo.

Os bits regulares do modo UNIX não fornecem o mesmo nível de granularidade em permissões que as ACLs NTFS ou NFSv4.x fornecem. A tabela a seguir compara a granularidade de permissão entre bits do modo NFSv3 e ACLs do NFSv4.1. Para obter informações sobre ACLs NFSv4.1, consulte "nfs4_acl - Listas de controle de acesso NFSv4" .

Por fim, a associação ao grupo NFS (tanto no NFSv3 quanto no NFSV4.x) é limitada a um máximo padrão de 16 para AUTH_SYS, conforme os limites de pacotes RPC. O NFS Kerberos fornece até 32 grupos e as ACLs NFSv4 removem a limitação por meio de ACLs granulares de usuários e grupos (até 1.024 entradas por ACE).

Além disso, o Google Cloud NetApp Volumes fornece suporte de grupo estendido para ampliar o número máximo de grupos suportados para até 32. Isso requer uma conexão LDAP com um servidor LDAP que contenha identidades de usuários e grupos UNIX válidas. Para obter mais informações sobre como configurar isso, consulte "Criação e gerenciamento de volumes NFS" na documentação do Google.

Com o NFSv3, o cliente e o servidor nunca precisam confirmar se o usuário que tenta uma leitura ou gravação com uma ID numérica é um usuário válido; ele é apenas implicitamente confiável. Isso expõe o sistema de arquivos a possíveis violações simplesmente falsificando qualquer ID numérica. Para evitar falhas de segurança como essa, há algumas opções disponíveis para o Google Cloud NetApp Volumes.

Em última análise, a segurança do NFS é limitada ao que a versão do protocolo que você está usando oferece. O NFSv3, embora tenha melhor desempenho em geral que o NFSv4.1, não oferece o mesmo nível de segurança.

Devido aos recursos de segurança adicionais no NFSv4.1, há algumas dependências externas envolvidas que não eram necessárias para usar o NFSv3 (semelhante a como o SMB requer dependências como o Active Directory).

O Google Cloud NetApp Volumes oferece suporte para ACLs NFSv4.x, que oferecem vantagens distintas sobre as permissões normais no estilo POSIX, como as seguintes:

As ACLs do NFSv4 são diferentes das ACLs de nível de arquivo do Windows (ACLs do NTFS), mas têm funcionalidade semelhante. No entanto, em ambientes NAS multiprotocolo, se as ACLs NFSv4.1 estiverem presentes e você estiver usando acesso de protocolo duplo (NFS e SMB nos mesmos conjuntos de dados), os clientes que usam SMB2.0 e versões posteriores não poderão visualizar ou gerenciar ACLs nas guias de segurança do Windows.

Para referência, os seguintes termos são definidos:

Quando um cliente define uma ACL NFSv4.1 em um arquivo durante uma operação SETATTR, o Google Cloud NetApp Volumes define essa ACL no objeto, substituindo qualquer ACL existente. Se não houver ACL em um arquivo, as permissões de modo no arquivo serão calculadas a partir de OWNER@, GROUP@ e EVERYONE@. Se houver algum bit SUID/SGID/STICKY existente no arquivo, eles não serão afetados.

Quando um cliente obtém uma ACL NFSv4.1 em um arquivo durante uma operação GETATTR, o Google Cloud NetApp Volumes lê a ACL NFSv4.1 associada ao objeto, constrói uma lista de ACEs e retorna a lista ao cliente. Se o arquivo tiver uma ACL NT ou bits de modo, uma ACL será construída a partir de bits de modo e retornada ao cliente.

O acesso será negado se uma DENY ACE estiver presente na ACL; o acesso será concedido se uma ALLOW ACE existir. Entretanto, o acesso também será negado se nenhuma das ACEs estiver presente na ACL.

Um descritor de segurança consiste em uma ACL de segurança (SACL) e uma ACL discricionária (DACL). Quando o NFSv4.1 interopera com o CIFS/SMB, o DACL é mapeado um-para-um com o NFSv4 e o CIFS. O DACL consiste em ALLOW e DENY ACEs.

Se um básico chmod é executado em um arquivo ou pasta com ACLs NFSv4.1 definidas, as ACLs de usuário e grupo existentes são preservadas, mas as ACLs padrão OWNER@, GROUP@, EVERYONE@ são modificadas.

Um cliente que usa ACLs do NFSv4.1 pode definir e visualizar ACLs para arquivos e diretórios no sistema. Quando um novo arquivo ou subdiretório é criado em um diretório que possui uma ACL, esse objeto herda todas as ACEs na ACL que foram marcadas com o apropriado "sinalizadores de herança" .

Se um arquivo ou diretório tiver uma ACL NFSv4.1, essa ACL será usada para controlar o acesso, independentemente do protocolo usado para acessar o arquivo ou diretório.

Arquivos e diretórios herdam ACEs de ACLs NFSv4 em diretórios pais (possivelmente com modificações apropriadas), desde que as ACEs tenham sido marcadas com os sinalizadores de herança corretos.

Quando um arquivo ou diretório é criado como resultado de uma solicitação NFSv4, a ACL no arquivo ou diretório resultante depende se a solicitação de criação de arquivo inclui uma ACL ou apenas permissões de acesso a arquivos UNIX padrão. A ACL também depende se o diretório pai tem uma ACL.

As permissões ACLs do NFSv4.1 usam uma série de valores de letras maiúsculas e minúsculas (como rxtncy ) para controlar o acesso. Para obter mais informações sobre esses valores de letras, consulte "COMO: Usar a ACL do NFSv4" .

"As ACLs do NFSv4 oferecem a capacidade de oferecer herança de ACL" . Herança de ACL significa que arquivos ou pastas criados abaixo de objetos com ACLs NFSv4.1 definidos podem herdar as ACLs com base na configuração do "Sinalizador de herança ACL" .

"Umask"é usado para controlar o nível de permissão no qual arquivos e pastas são criados em um diretório sem interação do administrador. Por padrão, o Google Cloud NetApp Volumes permite que o umask substitua ACLs herdados, o que é o comportamento esperado de acordo com "RFC 5661" .

As ACLs do NFSv4.1 têm formatação específica. O exemplo a seguir é um conjunto ACE em um arquivo:

O exemplo anterior segue as diretrizes de formato ACL de:

Um tipo de A significa "permitir". Os sinalizadores de herança não são definidos neste caso, porque o principal não é um grupo e não inclui herança. Além disso, como o ACE não é uma entrada de AUDITORIA, não há necessidade de definir sinalizadores de auditoria. Para obter mais informações sobre ACLs do NFSv4.1, consulte "http://linux.die.net/man/5/nfs4_acl" .

Se a ACL do NFSv4.1 não estiver definida corretamente (ou uma sequência de nomes não puder ser resolvida pelo cliente e pelo servidor), a ACL poderá não se comportar conforme o esperado, ou a alteração da ACL poderá não ser aplicada e gerar um erro.

Erros de amostra incluem:

As permissões do NFSv4.1 podem incluir atributos DENY explícitos para PROPRIETÁRIO, GRUPO e TODOS. Isso ocorre porque as ACLs do NFSv4.1 são negadas por padrão, o que significa que se uma ACL não for explicitamente concedida por uma ACE, ela será negada. Atributos DENY explícitos substituem quaisquer ACEs de ACESSO, explícitos ou não.

DENY ACEs são definidos com uma tag de atributo de D .

No exemplo abaixo, GROUP@ tem todas as permissões de leitura e execução, mas não tem acesso de gravação.

DENY ACEs devem ser evitadas sempre que possível porque podem ser confusas e complicadas; ALLOW ACLs que não são explicitamente definidas são implicitamente negadas. Quando DENY ACEs são definidos, os usuários podem ter acesso negado quando esperam que o acesso seja concedido.

O conjunto anterior de ACEs é equivalente a 755 bits de modo, o que significa:

Entretanto, mesmo que as permissões sejam ajustadas para o equivalente a 775, o acesso pode ser negado devido ao DENY explícito definido em EVERYONE.

O NFSv4.1 utiliza a lógica de mapeamento de domínio de ID como uma camada de segurança para ajudar a verificar se um usuário que tenta acessar uma montagem NFSv4.1 é realmente quem ele afirma ser. Nesses casos, o nome de usuário e o nome do grupo provenientes do cliente NFSv4.1 anexam uma sequência de nome e a enviam para a instância do Google Cloud NetApp Volumes . Se a combinação de nome de usuário/grupo e ID não corresponder, o usuário e/ou grupo será reduzido ao usuário padrão ninguém especificado no /etc/idmapd.conf arquivo no cliente.

Esta sequência de ID é um requisito para a adesão adequada às permissões, especialmente quando ACLs NFSv4.1 e/ou Kerberos estão em uso. Como resultado, dependências do servidor de serviço de nomes, como servidores LDAP, são necessárias para garantir a consistência entre clientes e Google Cloud NetApp Volumes para resolução adequada de identidade de nomes de usuários e grupos.

O Google Cloud NetApp Volumes usa um valor de nome de domínio de ID padrão estático de defaultv4iddomain.com . Os clientes NFS usam como padrão o nome de domínio DNS para suas configurações de nome de domínio de ID, mas você pode ajustar manualmente o nome de domínio de ID em /etc/idmapd.conf .

Se o LDAP estiver habilitado no Google Cloud NetApp Volumes, o Google Cloud NetApp Volumes automatizará o domínio do ID NFS para alterar o que está configurado para o domínio de pesquisa no DNS e os clientes não precisarão ser modificados, a menos que usem nomes de pesquisa de domínio DNS diferentes.

Quando o Google Cloud NetApp Volumes consegue resolver um nome de usuário ou nome de grupo em arquivos locais ou LDAP, a sequência de caracteres de domínio é usada e IDs de domínio não correspondentes são compactados para ninguém. Se o Google Cloud NetApp Volumes não conseguir encontrar um nome de usuário ou nome de grupo em arquivos locais ou LDAP, o valor de ID numérico será usado e o cliente NFS resolverá o nome corretamente (isso é semelhante ao comportamento do NFSv3).

Sem alterar o domínio do ID NFSv4.1 do cliente para corresponder ao que o volume do Google Cloud NetApp Volumes está usando, você verá o seguinte comportamento:

A seguir são mostrados os resultados do cenário anterior:

Quando os domínios de ID do cliente e do servidor correspondem, a mesma listagem de arquivos fica assim:

Para obter mais informações sobre esse problema e como resolvê-lo, consulte a seção "NFSv4.1 e o usuário/grupo nobody ."

Se você planeja usar o Kerberos com NFS, deverá ter o seguinte com o Google Cloud NetApp Volumes:

Um dos problemas mais comuns observados com uma configuração NFSv4.1 é quando um arquivo ou pasta é mostrado em uma lista usando ls como sendo propriedade do user:group combinação de nobody:nobody .

Por exemplo:

E o ID numérico é 99 .

Em alguns casos, o arquivo pode mostrar o proprietário correto, mas nobody como o grupo.

Quem é ninguém?

O nobody usuário no NFSv4.1 é diferente do nfsnobody usuário. Você pode visualizar como um cliente NFS vê cada usuário executando o id comando:

Com o NFSv4.1, o nobody usuário é o usuário padrão definido pelo idmapd.conf arquivo e pode ser definido como qualquer usuário que você queira usar.

Por que isso acontece?

Como a segurança por meio do mapeamento de sequências de nomes é um princípio fundamental das operações do NFSv4.1, o comportamento padrão quando uma sequência de nomes não corresponde corretamente é restringir esse usuário a um que normalmente não terá acesso a arquivos e pastas pertencentes a usuários e grupos.

Quando você vê nobody para o usuário e/ou grupo nas listagens de arquivos, isso geralmente significa que algo no NFSv4.1 está mal configurado. A diferenciação entre maiúsculas e minúsculas pode ser importante aqui.

Por exemplo, se user1@CVSDEMO.LOCAL (uid 1234, gid 1234) estiver acessando uma exportação, o Google Cloud NetApp Volumes deverá conseguir encontrar user1@CVSDEMO.LOCAL (uid 1234, gid 1234). Se o usuário no Google Cloud NetApp Volumes for USER1@CVSDEMO.LOCAL, não haverá correspondência (USER1 maiúsculo versus user1 minúsculo). Em muitos casos, você pode ver o seguinte no arquivo de mensagens no cliente:

O cliente e o servidor devem concordar que um usuário é realmente quem ele afirma ser, então você deve verificar o seguinte para garantir que o usuário que o cliente vê tenha as mesmas informações que o usuário que o Google Cloud NetApp Volumes vê.

Em quase todos os casos, se você ver nobody nas listagens de usuários e grupos de clientes, o problema é a tradução do ID de domínio do nome do usuário ou grupo entre o Google Cloud NetApp Volumes e o cliente NFS. Para evitar esse cenário, use o LDAP para resolver informações de usuários e grupos entre clientes e o Google Cloud NetApp Volumes.

Se você estiver usando o NFSv4.1, há um mapeamento de nome-string que ocorre durante as operações do NFS, conforme descrito anteriormente.

Além de usar /var/log/messages para encontrar um problema com IDs NFSv4, você pode usar o "nfsidmap -l" comando no cliente NFS para visualizar quais nomes de usuários foram mapeados corretamente para o domínio NFSv4.

Por exemplo, esta é a saída do comando depois que um usuário que pode ser encontrado pelo cliente e Google Cloud NetApp Volumes acessa uma montagem NFSv4.x:

Quando um usuário não mapeia corretamente no domínio de ID NFSv4.1 (neste caso, netapp-user ) tenta acessar a mesma montagem e toca em um arquivo, eles são atribuídos nobody:nobody , como esperado.

O nfsidmap -l a saída mostra o usuário pcuser na exibição, mas não netapp-user ; este é o usuário anônimo em nossa regra de política de exportação(65534 ).