Resumo

  • draft-ietf-nfsv4-posix-acls-02 propõe quatro atributos opcionais para expor ACLs POSIX Draft diretamente e declarar o modelo efetivamente usado nas decisões de acesso.
  • No escopo por objeto, um cliente antigo pode trocar a forma real, apagar as regras de permissão do outro modelo e deixar os ACEs AUDIT/ALARM em uma superfície separada.
  • O recibo completo liga capacidade, modelo, escrita ordenada, leitura atômica, identidade, Mask, decisão da operação e efeito no arquivo.

Quando um retorno de sucesso substitui a política

Um diretório usa POSIX Draft como forma real. Um grupo nomeado tem bits de escrita, limitados pelo ACE Mask. O cliente compatível lê a ACL de acesso, a ACL padrão e o modo; tudo parece consistente.

Depois, uma ferramenta antiga grava dacl. Se acl_trueform_scope for por objeto, o SETATTR bem-sucedido pode mudar aquele arquivo para ACL_MODEL_NFS4 e apagar as ACLs POSIX de acesso e padrão. O código de sucesso prova que a transição foi aceita; não prova que a política anterior permaneceu.

O caminho inverso também existe. Uma ACL POSIX não vazia pode trocar a forma real de NFSv4 para POSIX Draft e remover o dacl ALLOW/DENY. Os ACEs de AUDIT/ALARM continuam separados. Dizer apenas “a ACL foi atualizada” esconde qual modelo passou a controlar a próxima tentativa de acesso.

A revisão 02, de 7 de setembro de 2026, é um Internet-Draft ativo do grupo NFSv4 destinado a Standards Track e expira em 11 de março de 2027. Não é RFC, recurso obrigatório nem evidência geral de produto ou implantação.

Quatro atributos localizam a verdade operacional

acl_trueform distingue NFSv4, POSIX Draft e ausência de ACL. acl_trueform_scope informa se a escolha vale para um objeto, sistema de arquivos ou servidor. posix_access_acl governa o objeto atual; posix_default_acl fornece herança para novos filhos de um diretório.

O suporte é conjunto. Quem oferece um atributo de forma real precisa oferecer ambos. Um sistema de arquivos que oferece uma ACL POSIX deve oferecer as duas ACLs, os dois atributos de forma e os comportamentos de mode e mode_umask.

Mesmo assim, uma sessão NFSv4.2 não basta. O cliente pode desconhecer a extensão, o export pode não suportá-la e dois objetos vizinhos podem ter formas diferentes. Um recibo de capacidade precisa identificar servidor, export, sessão, filehandle, bitmap e época.

O Mask limita a permissão visível

Uma ACL POSIX estendida combina proprietário, grupo proprietário, outros, usuários e grupos nomeados e um Mask. Para grupos, um bit só é efetivo quando aparece na entrada e no Mask.

Assim, uma tela pode mostrar escrita no grupo enquanto o Mask a bloqueia. Os nove bits baixos do modo também não contam toda a história: na ACL estendida, os bits de grupo refletem o Mask, não necessariamente Group_obj.

Reproduzir a decisão exige principal autenticado, resolução de nomes, grupos suplementares, propriedade do objeto, ACEs correspondentes, Mask e operação. O array perfeitamente transportado é apenas uma parte desse cálculo.

A ACL padrão não autoriza o diretório

A ACL de acesso vale para o objeto. A ACL padrão só existe em diretório e entra na construção da ACL de filhos futuros; ela não concede acesso ao próprio diretório.

Na criação, a herança é intersectada com os bits de modo. Por isso mode_umask acompanha a extensão: o modo é fornecido, a herança é aplicada e só depois entram ACLs POSIX explícitas.

Auditar um filho requer a ACL padrão do pai na época da criação, modo/umask, ordem das operações e leitura final do filho. O estado atual do pai não recompõe necessariamente o passado.

Atomicidade preserva uma fotografia

No mesmo SETATTR, o modo deve ser aplicado antes da ACL POSIX. Misturar acl ou dacl com atributos POSIX no mesmo bitmap deve retornar NFS4ERR_INVAL. Nas leituras, o servidor deve adquirir forma, modo e ACLs de maneira atômica em relação a alterações concorrentes.

Isso evita uma resposta formada por épocas diferentes. Não impede uma mudança logo depois, nem garante que outro nó resolva o mesmo nome da mesma forma. Trate o resultado como snapshot versionado, não como autorização contínua.

Vazio não significa ausência de controle

No escopo por objeto, gravar posix_access_acl vazio pode apagar a forma POSIX e retornar a ACL_MODEL_NONE. Mas a leitura POSIX também é vazia quando a forma real é NFSv4.

Sem acl_trueform, os casos se confundem. Um objeto pode depender do modo; o outro, de uma ACL NFSv4. Normalizar vazio como “sem restrição” transforma falta de contexto em permissão.

Código experimental mantém seu limite

O rascunho registra trabalho experimental no FreeBSD e um patch Linux. Os testes relatam funcionamento de getfacl e setfacl, inclusive com muitas entradas. O próprio texto diz que os relatos são fornecidos por contribuidores, não verificados de forma independente, e não representam endosso do IETF ou catálogo de produtos.

Eles provam viabilidade dentro do escopo testado. Não provam inclusão em release, ativação padrão, toda transição de forma, todo mapeamento de identidade ou uma decisão real de acesso.

Oito recibos formam uma afirmação

Para dizer que um usuário podia escrever, registre: capacidade exata; forma real e escopo; escrita aceita na ordem correta; leitura atômica; identidade e grupos efetivos; cálculo de ACE, Mask, modo e herança; decisão da operação concreta; e efeito final no arquivo e na aplicação.

Os novos atributos fortalecem as quatro primeiras etapas. O ganho de segurança está em preservar a fronteira, não em deixar a ACL falar em nome de etapas que ainda não aconteceram.

Fontes