Resumo

  • O RFC 2054 recomendava TCP na porta 2049, depois UDP 2049, NFSv3 com filehandle público de comprimento zero e, conforme o erro, recuo para v2, PORTMAP e MOUNT.
  • O filehandle público fornecia um ponto inicial de namespace; não autenticava o cliente, autorizava o export, validava o caminho inteiro nem comprovava um READ bem-sucedido.
  • O LOOKUP multicomponente reduzia viagens, mas preservava condições próprias para caminhos canônicos ou nativos, links simbólicos e travessias de filesystem.

O caminho antigo tinha duas descobertas

NFS era um programa RPC. O binding service na porta 111 dizia onde um programa estava ouvindo. MOUNT não tinha porta conhecida, então o cliente consultava PORTMAP, localizava o serviço e chamava MOUNTPROC_MNT para converter um caminho exportado em filehandle inicial. Só depois começavam as operações NFS.

Essa divisão separava responsabilidades, mas cobrava latência e criava uma porta dinâmica difícil para filtros e proxies. Como servidores NFS normalmente se registravam outra vez na 2049 após reiniciar, o RFC 2054 propôs um padrão otimista: tentar TCP 2049; se a conexão fosse recusada, usar UDP 2049; consultar PORTMAP apenas quando os dois transportes não respondessem. A porta era uma hipótese forte, não uma garantia.

O tipo de erro escolhia o recuo

Depois do contato, o cliente presumia WebNFS e NFSv3 e normalmente enviava LOOKUP com o handle público v3. PROG_MISMATCH dizia que a versão do programa não correspondia; o passo correto era repetir com NFSv2 e seu handle público.

NFS3ERR_STALE, NFS3ERR_INVAL e NFS3ERR_BADHANDLE negavam outra premissa: o servidor não reconhecia o handle público. O cliente precisava então localizar MOUNT com PORTMAP e obter um identificador convencional da versão adequada. Recusa TCP, silêncio UDP, versão incompatível e handle inválido são evidências distintas, porque indicam saídas distintas.

O zero era encontro, não credencial

Filehandles comuns eram valores opacos criados pelo servidor. A exceção pública tinha 32 octetos zero no NFSv2 e comprimento zero no NFSv3. Não codificava inode, export, identidade, segredo ou autorização. Apenas invocava semântica especial a partir de um local escolhido pelo administrador.

O RFC 2055 impede a leitura ingênua da palavra “público”. Um destino fora de filesystem exportado exige erro. Um caminho que chega a outro export também pode ser negado: se o servidor depende da verificação feita por MOUNT, a ausência de MOUNT não lhe permite conceder automaticamente o segundo acesso. Servidores que verificam export em toda requisição têm mais liberdade, mas a autoridade vem dessa verificação.

Um pedido podia carregar muitos componentes

LOOKUP comum resolvia um nome por vez. A partir do handle público, WebNFS permitia pedir a/b/c de uma vez e receber o handle final. Menos mensagens não apagavam as regras do caminho.

Início ASCII indicava caminho canônico separado por barras e com escapes definidos. Barra inicial começava na raiz do servidor; sem barra, no diretório associado ao handle público. O byte 0x80 introduzia a sintaxe nativa do servidor. As duas formas escolhiam contratos de interpretação diferentes.

Links simbólicos exigiam outra rodada de raciocínio. O servidor seguia links intermediários, mas devolvia o handle quando o último componente era link; o cliente fazia READLINK. Alvo absoluto voltava ao ponto público. Alvo relativo substituía o componente que nomeara o link antes de novo LOOKUP. O procedimento só foi definido para links encontrados por caminho canônico multicomponente.

LOOKUP tradicional também não atravessava normalmente um mountpoint do servidor. A travessia pública só podia ocorrer quando o filesystem de destino era exportado e o servidor implementava a semântica do RFC 2055. O handle retornado comprovava uma resolução naquele instante, sob aquele namespace e política; nada dizia sobre segurança eterna de cada componente.

Não somar recibos como se fossem autoridade

Resposta na porta, reconhecimento do zero e sucesso do LOOKUP são três recibos. Acesso ao arquivo ainda pede identidade do servidor, autenticação e integridade quando necessárias, permissão de export e da operação, avaliação de links e travessias, conteúdo esperado e conclusão do READ. Durabilidade e resultado de aplicação precisam de observação própria.

O RFC 2054 herdou as considerações de segurança do NFS e RPC e previu negociação separada de autenticação, integridade e privacidade. O filehandle vazio nunca foi encarregado delas.

Fontes