Network File System

Suponemos que un cliente de un sistema de archivos (NFS) de red trata de montar un directorio sacado del servidor NFS a un directorio local. Para llevar a cabo esto, necesitara la siguiente orden:

# mount -t nfs maquina_remota:/home /dir_local

En esta orden especificamos el tipo de sistema de archivos que se va a montar con –t, la máquina remota y el directorio donde vamos a montarlo.

Esta orden lo que trata es conectar con el demonio rpc mountd que se está ejecutando en la máquina remota a través de RPC. El servidor comprueba los permisos del cliente sobre el directorio /home donde se va a montar y si los tiene se lleva a cabo el montaje como si fuera cualquier otro dispositivo físico. Una vez realizado el montaje, cuando se acceda al directorio del cliente se estará accediendo al directorio del servidor remoto.

Cuando el directorio /dir_local tenga ya montado el directorio /home de la máquina remota, la única protección que tienen los archivos de dicho directorio son sus permisos.

Al acceder a los archivos del directorio NFS se generará una llamada RPC al demonio rpc nfsd en el servidor, en la cual van incluidos los parámetros correspondientes al UID y el GID del usuario y el descriptor del archivo, con los que se comprobarán los permisos.

Suponiendo un escenario de estilo Unix en el que una máquina (el cliente) necesita acceder a los datos almacenados en otra máquina (el servidor NFS):

• El servidor implementa procesos de daemon NFS, que se ejecutan de forma predeterminada como nfsd, para que sus datos estén genéricamente disponibles para los clientes.
• El administrador del servidor determina qué poner a disposición, exportando los nombres y parámetros de los directorios, generalmente usando el archivo de configuración / etc / exports y el comando exportfs.
• La administración de seguridad del servidor asegura que pueda reconocer y aprobar clientes validados.
• La configuración de la red del servidor asegura que los clientes apropiados puedan negociar con ella a través de cualquier sistema de firewall.
• El equipo del cliente solicita acceso a los datos exportados, normalmente emitiendo un comando de montaje. El cliente le pregunta al servidor (rpcbind) qué puerto está usando el servidor NFS, el cliente se conecta al servidor NFS (nfsd), nfsd pasa la solicitud a mountd.
• Si todo va bien, los usuarios de la máquina cliente pueden ver e interactuar con los sistemas de archivos montados en el servidor dentro de los parámetros permitidos.
• Tenga en cuenta que la automatización del proceso de montaje de NFS puede tener lugar, tal vez utilizando / etc / fstab y / o instalaciones de montaje.

Este sistema de archivos se utiliza para que en una red local diferentes equipos puedan acceder a archivos y compartirlos, de esta manera, una equipo puede acceder a la información de otro equipo como si fuera un disco duro. NFS se centra en la consistencia, asumiendo operaciones write pesadas que probablemente no sean muy frecuentes.

Uno de los usos principales del protocolo NFS es para poder tener todos los archivos centralizados en un único servidor. Esto va a permitir prescindir de unidades de memoria en los demás equipos y poder entrar de forma remota para leer cualquier archivo o descargarlo.

Es muy útil especialmente cuando son muchos los usuarios que van a tener que entrar para modificar esos archivos

• Múltiples clientes pueden acceder a los archivos.
• Reduce la necesidad de tener espacio en disco.
• Cualquier usuario puede modificar y actualizar los archivos.
• Compatibilidad con muchos equipos.
• Bajo costo para compartir archivos en red.
• Administración centralizada reduce necesidad de software y espacio en disco de usuarios.

• Seguridad: solo hay que usarlo en redes seguras y detrás de un firewall.
• Requiere de una gran sobrecarga para leer archivos.
• No es sencillo bloquear archivos o dar permisos.

El cliente simula las funcionalidades del sistema de archivos de UNIX, integrado directamente en el kernel. Se encarga de controlar las peticiones del VFS al servidor. Manda los bloques o archivos desde el servidor y hasta el servidor. Cuando es posible almacena en la caché local los bloques.

El módulo cliente de NFS guarda en caché los resultados de las operaciones <readwritegetattlookup> y readdir. Los clientes son responsables de sondear al servidor para comprobar la actualidad de sus datos de caché.

Método de marcas temporales para mantener las cachés:

Cada elemento es etiquetado con dos tiempos diferentes, uno el de la última vez que se validó el elemento y otro la última vez que fue modificado en el servidor. Una entrada en caché es válida en un momento t si t-tiempo que se validó por última vez es menor que el intervalo de refresco tolerado. Si no es válida la entrada se obtiene el tiempo en el que se modificó por última vez en el servidor y si es igual al del cliente, entonces la entrada es válida y se actualiza el tiempo del cliente, si no la entrada es invalida.

Para minimizar las llamadas a getattr, cuando se recibe un valor del servidor de un archivo, se aplica a todas las entradas relevantes de dicho archivo.

Aún con esto habrá problemas de consistencia si tenemos escrituras en dos clientes con una diferencia de tiempo menos que el intervalo de refresco tolerado. Para solucionar este problema tendremos que usar bloqueo de archivos convirtiendo en una sección crítica el archivo, esto se consigue en NFS mediante el protocolo Network Lock Manager (NLM).

El servidor NFS es parte del núcleo Linux, en los núcleos que Debian provee está compilado como un módulo de núcleo. Su interfaz está definida en el RFC 1813.

Se encarga de recibir las peticiones, que pueden ser similares a las de modelo de archivos plano o pueden simular las del sistema de UNIX.

El servidor también ofrece servicios de montaje, de control de autenticación y acceso y una caché.

Hay dos opciones para mantener y asegurar la consistencia en escritura:

• write-through: los datos de las operaciones de escritura se guardan en caché y se escriben en disco antes de responder al cliente.
• Commit: los datos de las operaciones de escritura se guardan solo en caché. Solo se escriben a disco cuando se recibe una operación commit.

Los demonios imprescindibles del servicio NFS son los siguientes:

• rpc.mountd: demonio que se encarga del montaje remoto. Recibe la petición desde el cliente NFS y comprueba que el sistema de archivos este exportado y si está disponible permite las solicitudes de acceso de NFS y proporciona información sobre ello (showmount).
• rpc.nfsd: demonio para servir archivos. Se pueden arrancar varias copias de este demonio. Utiliza el puerto TCP/UDP 2049.
• rpc.portmap: Se encarga de indicar a los clientes donde se encuentra el servicio real en el servidor. Los servicios basados en RPC usan portmap para atender las peticiones de los clientes por lo cual este servicio debe estar disponible el primero. No se utiliza en NFSv4. Para comprobar que está activo ejecutar:

  • # portmap status

• rpc.lockd: encargado de proporcionar el servicio de bloqueo de archivos para asegurar su consistencia ya que pueden ser accedidos de forma concurrente. Se ejecuta tanto en el servidor como en el cliente.
• rpc.statd: Este demonio trabaja conjuntamente con lockd para recuperar en caída de sistemas. Mantiene información sobre los procesos en los clientes que poseen locks de archivos de determinado servidor. Cuando el servidor NFS se recupera statd informa a los otros de los clientes, que el servidor se ha recuperado y así ellos resuelven los locks que tenían.

Si queremos que nuestro servicio NFS sea más seguro deberíamos tener en cuenta una serie de detalles, como son:

1. Utilizar los comodines (metacaracteres) lo menos posible, ya que podemos dar acceso a más equipos de los que estamos pensando.
2. Utilizar reglas de Iptables (cortafuegos) para limitar el acceso a los puertos utilizados por los demonios del servicio NFS.
3. El uso de los archivos /etc/hosts.allow y /etc/hosts.deny no es obligatorio pero es preferible configurarlos para garantizar la seguridad de los datos.
4. Exportar sistemas de archivos de lectura (ro) siempre que sea posible.
5. El dueño de los archivos y directorios exportados que sea root ya que es posible mapear el UID de root al del usuario nobody.
6. Intentar que los archivos exportados no tengan permiso de escritura para el grupo (ACL).
7. Las versiones 2 y 3 de NFS no disponen de control de acceso para los usuarios concretos. En ellas, cuando un sistema de archivos es exportado, cualquier usuario en cualquier máquina remota conectada al servidor NFS puede acceder a los datos compartidos. El único mecanismo de seguridad que tienen es utilizar el acceso de solo lectura y reducir todos los usuarios a uno común cuyo UID y GID especificamos.
8. Si no se utiliza la opción de exportación squash, cualquier usuario root en el equipo cliente puede convertirse en un usuario con acceso privilegiado simplemente ejecutando la orden: su - . Conviene siempre tener activada alguna opción de squash.
9. La versión más segura de NFS es la 4.

NFS incluye la identidad del usuario por defecto en las peticiones al servidor, pero solo para compararla con los permisos de accesos, no la valida.

Con kerberos se realiza la autenticación del usuario en el momento del montaje del sistema de archivos. Los resultados de estas autenticaciones se almacenan y se utilizan en cada petición NFS. Esto protege contra la mayoría de ataques.

Las versiones de NFS más importantes son NFSv2 (RFC 1094), NFSv3 (RFC 1813) y NFSv4 (RFC 3530).

La versión 2 de NFS es la más utilizada y soportada por los sistemas operativos, a la vez que la más antigua e insegura. La versión 3 es más potente que la 2 pero no es compatible completamente con los clientes de la versión anterior. Estas dos versiones pueden trabajar tanto con TCP como con UDP como protocolo de transporte creando conexiones de red entre cliente y servidor. La ventaja de utilizar UDP es que se minimiza el tráfico de red, pero si se cayera los clientes seguirían mandando mensaje y se saturaría.

En general las versiones 2 y 3 de NFS permiten controlar la exportación y montaje de sistemas de archivos en función del equipo que hace la solicitud, pero no del usuario. Es decir no se contempla un control de acceso al sistema de archivos por usuario. Solo para los equipos. Esto implica que si un sistema de archivos es exportado desde el servidor NFS, cualquier usuario de un equipo remoto cliente NFS podría acceder a él. Los únicos mecanismos de seguridad que quedan en este caso son los permisos de acceso (solo lectura) o utilizar un usuario y grupo únicamente. Lógicamente esto limita bastante la idea de compartición que tenemos todos.

En el caso de la versión 4 de NFS estos problemas de seguridad desaparecen pero, a cambio, tiene unos requerimientos de configuración y servicios adicionales mucho más importantes. Por ejemplo, en la versión 4 la utilización de mecanismos para la autenticación de los usuarios es obligatoria. Para ello y en función del tipo de seguridad seleccionada, se requiere la utilización del servicio Kerberos cuya misión será funcionar como servidor de entrega de tickets (KDC) y que debe estar configurado y funcionando correctamente antes de configurar  el servidor NFSv4. Este requerimiento proporciona seguridad al servicio NFS a cambio de incluir mayor complejidad a su configuración y puesta a punto.

Otra característica importante de NFS4 es la utilización de ACLs (Listas de Control de Acceso) al estilo Windows y que no son soportadas por las versiones 2 y 3 de NFS. Cuando hablamos de ACLs nos referimos a los permisos o derechos de acceso que tiene cada usuario sobre un archivo o directorio y que vienen especificados a modo de listas editables por el administrador del sistema.

• Reducen el riesgo de que el fallo de un solo equipo impida acceder a los datos.
• Proporcionan ubicaciones centralizadas para los datos que deben o deberían estar compartidas entre todos los usuarios.
• Simplifican el acceso a los datos existentes en sistemas más veloces.
• Proporcionan la oportunidad de centralizar operaciones administrativas, tales como la copia de seguridad de los datos (back-ups).
• Proporcionan interoperabilidad y flexibilidad. Normalmente se puede acceder a sistemas de ficheros en red desde ordenadores que ejecuten Linux, Windows, Mac OS X, BeOS, BSD, y muchos otros. De esta forma es fácil utilizar el hardware y software más adecuado a los requerimientos de escritorio, y aun así acceder a los mismos datos del entorno de sistema de ficheros en red.

• NFSv2 y NFSv3 pueden utilizar UDP como protocolo de transporte que al ser una conexión desatendida, minimiza el tráfico de red, pero si el servidor NFS cayera por cualquier circunstancia, los clientes NFS seguirían enviando peticiones al servidor produciendo el efecto contrario, que es la saturación de la red.
• Las versiones 2 y 3 de NFS permiten controlar la exportación y montaje de sistemas de archivos en función del equipo que hace la solicitud, pero no del usuario. Es decir no se contempla un control de acceso al sistema de archivos por usuario. Solo para los equipos. Esto implica que si un sistema de archivos es exportado desde el servidor NFS, cualquier usuario de un equipo remoto cliente NFS podría acceder a él.
• NFS sufre algunos problemas de rendimiento debido a su diseño “sin estado” (parte de estos problemas son mitigados en las últimas versiones de NFS). En particular, como el cliente asume que una operación de escritura se completa una vez que recibe el acuse de recibo del servidor, el servidor debe asegurarse de escribir cada bloque a disco antes de responder, para evitar discrepancias en el caso de una caída. Esto introduce un retardo significativo en el caso de escrituras NFS.

Inicialmente NFS soportaba 18 procedimientos para todas las operaciones básicas de E/S.^[1]​ Los comandos de la versión 2 del protocolo son los siguientes:^[2]​

• NULL: no hace nada, pero sirve para hacer ping al server y medir tiempos.
• CREATE: crea un nuevo archivo.
• LOOKUP: busca un fichero en el directorio actual y si lo encuentra, devuelve un descriptor a ese fichero más información sobre los atributos del fichero.
• READ y WRITE: primitivas básicas para acceder el fichero.
• RENAME: renombra un fichero.
• REMOVE: borra un fichero.
• MKDIR y RMDIR: creación/borrado de subdirectorios.
• READDIR: para leer la lista de directorios.
• GETATTR y SETATTR: devuelve conjuntos de atributos de ficheros.
• LINK: crea un archivo, el cual es un enlace a un archivo en un directorio, especificado.
• SYMLINK y READLINK: para la creación y lectura, respectivamente, de enlaces simbólicos (en un "string") a un archivo en un directorio.
• STATFS: devuelve información del sistema de archivos.
• ROOT, para ir a la raíz (obsoleta en la versión 2).
• WRITECACHE: reservado para un uso futuro.

En la versión 3 del protocolo se eliminan los comandos STATFS, ROOT y WRITECACHE; y se agregaron los siguientes:^[3]​

• ACCESS: Para verificar permisos de acceso.
• MKNOD: Crea un dispositivo especial.
• READDIRPLUS: una versión mejorada de READDIR.
• FSSTAT: devuelve información del sistema de archivos en forma dinámica.
• FSINFO: devuelve información del sistema de archivos en forma estática.
• PATHCONF: Recupera información POSIX.
• COMMIT: Enviar datos de caché sobre un servidor un sistema de almacenamiento estable.

La versión 4 fue publicada en abril de 2003 y no es compatible con las versiones anteriores. Soporta 41 comandos: NULL, COMPOUND, ACCESS, CLOSE, COMMIT, CREATE, DELEGPURGE, DELEGRETURN, GETATTR, GETFH, LINK, LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, OPEN_DOWNGRADE, PUTFH, PUTPUBFH, PUTROOTFH, READ, READDIR, READLINK, REMOVE, RENAME, RENEW, RESTOREFH, SAVEFH, SECINFO, SETATTR, SETCLIENTID, SETCLIENTID_CONFIRM, VERIFY, WRITE, RELEASE_LOCKOWNER, ILLEGAL.^[4]​

Temas relacionados con NFS:

• ONC RPC, llamada a procedimiento remoto utilizado con NFS.
• XDR, protocolo de presentación de datos utilizado por NFS.
• VFS, sistema de archivos virtual.

Otros sistemas:

• AppleTalk
• Samba (software)
• Server Message Block
• Andrew File System
• Secure Shell Filesystem

• Linux NFS (en inglés)
• El Sistema de Ficheros de Red Proyecto de Documentación de Linux. Guía de Administración de Redes con Linux, Capítulo 14.
• Microsoft financia un cliente Open Source de NFS v4 para Windows
• [1] Santamaria, R. Sistemas Distribuidos.
• [2] Ministerio de Educación,Cultura y Deporte de España