Resumen

  • draft-ietf-nfsv4-posix-acls-02 propone cuatro atributos opcionales para transportar ACL POSIX Draft directamente y declarar qué modelo utiliza realmente el servidor al decidir el acceso.
  • Con alcance por objeto, una escritura de un cliente antiguo puede cambiar el modelo real, borrar las reglas del otro modelo y conservar por separado los ACE de auditoría y alarma.
  • Una prueba completa enlaza capacidad, modelo, escritura ordenada, lectura atómica, principal, grupos, máscara, decisión de la operación y efecto observado.

Dos clientes, un archivo y dos políticas distintas

Un servidor guarda una ACL POSIX Draft como forma real. La entrada de un grupo contiene escritura, aunque el ACE Mask limita qué bits son efectivos. Un cliente moderno lee posix_access_acl, posix_default_acl y el modo; la imagen es coherente.

Después, una herramienta antigua escribe dacl. Si el servidor usa alcance por objeto, esa operación puede cambiar el archivo a ACL_MODEL_NFS4 y borrar las ACL POSIX de acceso y por defecto. La respuesta de SETATTR es satisfactoria. Sin embargo, no confirma que la política anterior se haya conservado; confirma precisamente una transición que pudo reemplazarla.

También puede ocurrir al revés: escribir una ACL POSIX no vacía cambia la forma real a POSIX Draft y elimina el dacl ALLOW/DENY de NFSv4. Los ACE AUDIT/ALARM no siguen automáticamente ese cambio. Una consola que muestre solo «ACL actualizada» oculta la parte decisiva: cuál es ahora el modelo autoritativo.

La revisión 02, publicada el 7 de septiembre de 2026, es un Internet-Draft activo del grupo NFSv4 con destino Standards Track y fecha de expiración de 11 de marzo de 2027. No es un RFC ni una prueba de adopción o conformidad de producto.

La forma real tiene alcance

acl_trueform declara NFSv4, POSIX Draft o ausencia de ACL. acl_trueform_scope sitúa esa decisión en el objeto, el sistema de archivos o el servidor. Los otros dos atributos separan la ACL de acceso del objeto de la ACL por defecto que un directorio entrega a futuros hijos.

El soporte viene en conjuntos: quien expone un atributo de forma real debe exponer ambos; quien soporta una ACL POSIX en un sistema de archivos debe soportar las dos ACL, la forma y el alcance, además de mode y mode_umask.

Esto mejora la introspección, pero no elimina la negociación. Un cliente NFSv4.2 puede ignorar la extensión. Un export puede no ofrecerla. Con alcance por objeto, dos archivos contiguos pueden tener formas reales distintas. Por eso la evidencia debe incluir sesión, servidor, export, filehandle, bitmap, alcance y tiempo.

El Mask define el techo efectivo

Una ACL POSIX extendida contiene propietario, grupo propietario, otros, usuarios o grupos nombrados y un Mask. Para el grupo propietario y los grupos nombrados, un permiso solo es efectivo si el bit existe tanto en la entrada como en el Mask.

Mostrar una entrada aislada exagera el poder. Mostrar solo los nueve bits bajos del modo también puede engañar, porque en una ACL extendida los bits de grupo reflejan el Mask, no necesariamente Group_obj.

La decisión necesita conocer al principal autenticado, su resolución de nombre, grupos suplementarios, propiedad del objeto, ACE coincidentes, Mask y operación. Ningún campo ACL por sí solo puede demostrar esa combinación.

Heredar no es conceder acceso al directorio

La ACL de acceso controla el objeto actual. La ACL por defecto solo vive en un directorio y participa en la construcción de los permisos de hijos futuros. No autoriza el acceso al propio directorio.

En una creación, los permisos heredados se intersectan con el modo suministrado. mode_umask preserva esa semántica: primero se aplica el modo, después la herencia y luego cualquier ACL POSIX explícita.

Una auditoría posterior necesita la ACL por defecto del padre en la época de creación, el modo solicitado, el orden y la lectura final del hijo. La ACL actual del padre no reconstruye necesariamente el pasado.

La atomicidad fija una época, no el futuro

Si un SETATTR incluye modo y ACL POSIX, el modo se aplica primero. Si intenta mezclar acl o dacl con atributos POSIX, el servidor debe responder NFS4ERR_INVAL. Para leer, el borrador recomienda adquirir de forma atómica modo, forma real y ACL frente a escrituras concurrentes.

La fotografía resultante es valiosa. Evita combinar campos de épocas distintas. Pero otro cliente puede cambiar el objeto inmediatamente después. Tampoco demuestra que la identidad se resuelva igual en todo el clúster ni que una futura apertura use la misma política.

El vacío tiene más de un significado

En alcance por objeto, escribir posix_access_acl con longitud cero puede borrar la ACL POSIX y llevar la forma real a ACL_MODEL_NONE. Al leer, una matriz POSIX también debe aparecer vacía cuando la forma real sea NFSv4.

Sin acl_trueform, ambos casos parecen iguales. En uno mandan los bits de modo; en otro hay una ACL NFSv4 que el atributo POSIX no pretende representar. Convertir «vacío» en «sin restricciones» elimina la incertidumbre justo donde más importa.

Las implementaciones del borrador son pruebas acotadas

El texto registra software experimental de FreeBSD y un parche Linux. Los informes dicen que getfacl y setfacl funcionaron y que se probaron listas grandes. El propio borrador advierte que son datos aportados por colaboradores, no verificados de forma independiente, y que no constituyen aprobación del IETF ni catálogo de productos.

Sirven para demostrar factibilidad. No prueban inclusión en una versión, activación por defecto, cada transición de modelo, resolución de identidades ni corrección de una decisión real.

La cadena de ocho recibos

La afirmación «este usuario podía escribir» exige ocho pruebas: capacidad exacta; forma real y alcance; escritura aceptada en orden; lectura atómica; identidad y grupos efectivos; cálculo de ACE, Mask, modo y herencia; decisión sobre la operación concreta; y efecto final sobre archivo y aplicación.

La extensión fortalece las primeras cuatro. Su mejor uso es hacer visibles los límites, no presentar la ACL como sustituto de la decisión que todavía debe ejecutar el servidor.

Fuentes