Resumen

  • El cliente de RFC 2054 intentaba primero TCP 2049, luego UDP 2049, suponía NFSv3 y un identificador público de longitud cero, y retrocedía por errores concretos hacia v2, PORTMAP y MOUNT.
  • El identificador público era un punto inicial reservado; no autenticaba, no autorizaba un export, no validaba todos los componentes de una ruta ni demostraba que READ entregara el archivo esperado.
  • El LOOKUP de varios componentes ahorraba rondas, pero mantenía reglas diferentes para rutas canónicas y nativas, enlaces simbólicos y cruces de sistemas de archivos.

La ruta convencional separaba descubrimiento y montaje

NFS funcionaba sobre RPC. El servicio de enlace del puerto 111 relacionaba un número de programa con un puerto asignado. Como MOUNT no tenía puerto conocido, el cliente consultaba PORTMAP, localizaba MOUNT y enviaba MOUNTPROC_MNT para convertir una ruta exportada en el primer filehandle. Solo después podía operar con NFS.

La separación tenía sentido, pero añadía viajes y un puerto dinámico difícil de atravesar mediante filtros o proxies. RFC 2054 convirtió el uso habitual del 2049 en una hipótesis operativa: abrir TCP 2049; ante rechazo, usar UDP 2049; consultar PORTMAP únicamente cuando ninguno de los dos produzca respuesta. La secuencia no certificaba el puerto. Definía cómo dejar de creer en él.

El error señalaba qué supuesto había caído

Con el servidor localizable, el cliente suponía WebNFS y NFSv3. Normalmente enviaba LOOKUP con el filehandle público v3. PROG_MISMATCH indicaba que la versión del programa no coincidía y justificaba otro intento con v2 y su identificador público.

NFS3ERR_STALE, NFS3ERR_INVAL o NFS3ERR_BADHANDLE tenían otro significado: el servidor no reconocía el valor público. La respuesta correcta era abandonar el atajo y usar PORTMAP y MOUNT para conseguir un identificador inicial ordinario. Un rechazo TCP, el silencio UDP, una incompatibilidad de versión y un handle inválido no son cuatro nombres de la misma avería; son límites de evidencia distintos.

El cero nombraba un comienzo

Los filehandles comunes eran valores opacos creados por el servidor. El público era una excepción reservada: 32 octetos cero en NFSv2 y longitud cero en NFSv3. No contenía inode, usuario, export, secreto ni derecho. Activaba una interpretación desde el punto que el administrador hubiese asociado con él.

RFC 2055 deja claro que “público” no equivale a “autorizado”. Si el destino no está exportado, el servidor debe devolver un error. Incluso el salto a otro sistema de archivos exportado puede ser improcedente: un servidor que confía en la comprobación de MOUNT no puede conceder automáticamente acceso al segundo export cuando WebNFS ha omitido MOUNT. Solo una comprobación por operación permite decidirlo de otro modo.

Menos mensajes no significaban menos semántica

Un LOOKUP ordinario resolvía un componente. Desde el identificador público, WebNFS permitía enviar a/b/c en una sola petición. El servidor devolvía el handle del componente final.

La ruta seguía teniendo modalidad. Un inicio ASCII elegía la forma canónica separada por barras y sus escapes. Una barra inicial empezaba en la raíz del servidor; sin ella, en el directorio asociado al identificador público. El octeto inicial 0x80 anunciaba sintaxis nativa. Cada forma definía quién interpretaba qué caracteres.

Los enlaces simbólicos abrían otra decisión. El servidor evaluaba los enlaces intermedios, pero si el componente final era un enlace devolvía su handle para que el cliente hiciera READLINK. Un destino absoluto se reenviaba desde el identificador público; uno relativo se sustituía en la ubicación del enlace antes de un nuevo LOOKUP. RFC 2054 solo definía esta conducta para enlaces obtenidos mediante ruta canónica de varios componentes.

Los cruces de filesystem tampoco eran gratuitos. LOOKUP normalmente no atravesaba un punto de montaje del servidor. La variante pública podía hacerlo únicamente si el destino estaba exportado y el servidor implementaba la extensión de RFC 2055. El handle final probaba una resolución concreta bajo un estado y una política concretos; no probaba la integridad permanente de toda la ruta.

Tres hechos no forman una autorización

Que 2049 responda, que el cero sea reconocido y que LOOKUP devuelva un handle son tres recibos. Para afirmar acceso al archivo todavía hacen falta identidad, autenticación e integridad cuando correspondan, permiso del export y de la operación, tratamiento seguro de enlaces y cruces, contenido esperado y finalización de READ. Persistencia y resultado de negocio pertenecen a comprobaciones posteriores.

RFC 2054 heredó las consideraciones de seguridad de NFS y RPC y dejó autenticación, integridad y privacidad a una negociación separada. El valor cero nunca recibió esas atribuciones.

Fuentes