Resumo
- O grupo NFSv4 publicou em 29 de setembro a versão
-06de ACLs within the NFSv4 Protocols. O atributo opcional propostoACL_Choicesai da posição 87 e passa à 89; outros rascunhos usam 87 para dados de arquivo não armazenáveis em cache e 88 para metadados de entradas de diretório. - Os códigos de quatro erros relativos ao tamanho de ACL passam de 20000–20003 a 10095–10098. A nova redação só permite usá-los quando
AclChoiceé suportado pelo servidor e pelo sistema de arquivos alvo. A própria seção ainda pede consenso.
Um número visto em um teste de protocolo conta uma história curta: o software reconheceu determinado identificador. Não conta, por si, qual revisão serviu de base ao par cliente-servidor nem se uma capacidade de segurança está ativa naquele volume. Essa distinção aparece no contraste entre as versões -05 e -06 do rascunho de ACL do NFSv4. Em 14 de setembro, ACL_Choice aparecia como atributo 87. Em 29 de setembro, o quadro e a constante XDR apontam 89. O histórico da nova versão diz que a mudança abriu espaço para duas propostas sobre cache: uncacheable_file_data, número 87, e uncacheable_dirent_metadata, número 88.
Isso é coordenação entre documentos em elaboração. O primeiro atributo pretende informar ao cliente escolhas de comportamento de listas de controle de acesso na revisão de NFSv4.1; os demais tratam da atualização de dados de arquivos e de metadados de diretório. São funções diferentes. Não há registro, nas fontes públicas usadas aqui, de choque em um serviço de produção, de dispositivo afetado ou de uso universal do valor antigo. Também seria prematuro tratar as três posições como designações imutáveis de um RFC já publicado.
A alteração dos erros impõe um cuidado adicional. O texto descreve situações em que uma ACL não cabe para armazenamento ou não pode ser devolvida, usando NFS4ERR_ACLST_POORFIT, NFS4ERR_ACLST_NOFIT, NFS4ERR_ACLST_TOOBIG e NFS4ERR_ACLFT_TOOBIG. Os valores que eram 20000 a 20003 passam a 10095 a 10098. A versão mais recente acrescenta uma trava: nenhum deles deve ser devolvido por um servidor sem AclChoice, nem para um sistema de arquivos específico que não suporte esse atributo. A condição acompanha a operação concreta, não apenas a etiqueta do servidor.
Pense em duas exportações do mesmo equipamento, apoiadas em sistemas de arquivos distintos. Um teste confirma a presença do atributo na primeira. Um decodificador atualizado vê um dos novos códigos ao testar a segunda. Sem conferir o suporte da segunda exportação, concluir que ambas oferecem a mesma semântica ACL seria um salto indevido. Esse exemplo delimita uma verificação possível; não relata um erro encontrado em fornecedor algum.
No Datatracker, -06 continua ativo como documento do grupo de trabalho, no estado I-D Exists. A capa prevê atualizar RFC 7530 e RFC 8881 apenas se houver aprovação. O texto menciona trabalho rumo a uma futura última chamada do grupo e mantém a marca de consenso pendente na seção dos erros. Portanto, a expressão normativa proposta ali não substitui hoje os RFCs vigentes. O passo útil para integradores é associar cada resultado de ensaio à revisão do rascunho e ao sistema de arquivos efetivamente acessado.
Fontes
- https://www.ietf.org/archive/id/draft-ietf-nfsv4-acls-update-05.txt
- https://www.ietf.org/archive/id/draft-ietf-nfsv4-acls-update-06.txt
- https://datatracker.ietf.org/doc/draft-ietf-nfsv4-acls-update/
- https://www.ietf.org/archive/id/draft-ietf-nfsv4-uncacheable-files-16.txt
- https://www.ietf.org/archive/id/draft-ietf-nfsv4-uncacheable-directories-12.txt
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance

