OneFS: La actualización del kernel de Linux a NFS provoca fallas en las llamadas de "acceso"

Después de una actualización del kernel de Linux, las comprobaciones de acceso que anteriormente se habían realizado correctamente ahora fallan en los directorios en los que el usuario que accede no tiene permisos de "delete_child" en un directorio relacionado con su flujo de trabajo. Esto se puede validar mediante Linux test con el comando -w en ese mismo directorio; En versiones antiguas del kernel, el código de retorno de ese comando es 0 mientras que en los kernels más nuevos es 1.

Esto afecta a los clientes de Red Hat y Centos que pasan de la versión 7 a las versiones más recientes.

Este cambio en el comportamiento se introdujo en el kernel principal de Linux v4.13-rc2 durante una refactorización del código del controlador de NFS. Sin embargo, aparentemente la comprobación estaba presente a partir del kernel principal v3.7-rc1, y no se llamaba correctamente.

Después de una revisión exhaustiva, creemos que tanto el nuevo comportamiento del kernel de Linux como nuestro comportamiento son correctos. La versión de Linux test comando y access Las llamadas al sistema se basan en el estándar POSIX, que solo conceptualiza:

• LEER
• ESCRIBIR
• EJECUTAR

Considerando que , según rfc1813#section-3.3.4 y rfc7530#section-16.1; NFS permite permisos más granulares y, por lo tanto, conceptualiza lo siguiente:

• LEER
• MODIFICAR
• AÑADIR
• BORRAR
• EJECUTAR

Con el permiso DELETE definido como si un cliente puede Delete an existing directory entry. Esto se asigna directamente a delete_child en OneFS, y se debe denegar en circunstancias en las que el cliente no tiene ese permiso. También tenga en cuenta; Los permisos de POSIX y NFS no coinciden exactamente. POSIX WRITE incluye todos los conceptos de los permisos MODIFY, APPEND y DELETE independientes de NFS. Por lo tanto, cuando una herramienta POSIX intenta comprobar los permisos de "ESCRITURA", el kernel de Linux está traduciendo esa solicitud de "ESCRITURA" en "MODIFICAR, ANEXAR y ELIMINAR"

Por último, el comportamiento más reciente está más en línea con otros controladores del sistema de archivos Linux que también admiten este conjunto de permisos. Por ejemplo, la prueba contra un filer SMB con el mismo conjunto de permisos también devuelve una falla cuando se comprueba POSIX WRITE con el test mediante el comando -w bandera.
 

# Old kernel
ancons@ubuntu:~$ uname -r
4.13.0-041300rc1-generic
ancons@ubuntu:~$ sudo mount -o vers=4,proto=tcp 10.20.0.181:/ifs /mnt/nfs
ancons@ubuntu:~$ sudo mount -o user=admin,pass=a //10.20.0.181/ifs /mnt/smb
ancons@ubuntu:~$ test -w /mnt/nfs/posix; echo "$?"
0
ancons@ubuntu:~$ test -w /mnt/smb/posix; echo "$?"
1

# New kernel
ancons@ubuntu:~$ uname -r
4.14.0-041400rc4-generic
ancons@ubuntu:~$ sudo mount -o vers=4,proto=tcp 10.20.0.181:/ifs /mnt/nfs
ancons@ubuntu:~$ sudo mount -o user=admin,pass=a //10.20.0.181/ifs /mnt/smb
ancons@ubuntu:~$ test -w /mnt/nfs/posix; echo "$?"
1
ancons@ubuntu:~$ test -w /mnt/smb/posix; echo "$?"
1

Los comportamientos de OneFS y Linux en esta circunstancia son correctos, ya que los flujos de trabajo afectados por este problema deben proporcionar la delete_child Permiso para usuarios y grupos afectados. Por ejemplo, si un directorio proporciona acceso completo a su usuario y grupo propietario, pero elimina delete_child desde el permiso para todos, pueden agregar ese permiso a todos o pueden agregar una entrada de control de acceso (ACE) adicional para el usuario o grupo que está viendo problemas en la lista de control de acceso (ACL) de directamente.

# ACL that only allows root to delete child items
p980-1-1# ls -led /ifs/posix-delete_child
drwxrwxrwx +   2 root  wheel  0 Jun 18 14:20 /ifs/posix-delete_child
 OWNER: user:root
 GROUP: group:wheel
 0: user:root allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
 1: group:wheel allow dir_gen_read,dir_gen_write,dir_gen_execute,delete_child
 2: everyone allow dir_gen_read,dir_gen_write,dir_gen_execute

# ACL that allows a specific additional group to delete child items
p980-1-1# ls -led /ifs/posix-delete_child
drwxrwxrwx +   2 root  wheel  0 Jun 18 14:20 /ifs/posix-delete_child
 OWNER: user:root
 GROUP: group:wheel
 0: group:admin allow dir_gen_read,dir_gen_write,dir_gen_execute,delete_child
 1: user:root allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
 2: group:wheel allow dir_gen_read,dir_gen_write,dir_gen_execute,delete_child
 3: everyone allow dir_gen_read,dir_gen_write,dir_gen_execute

# ACL that allows everyone to delete child items
p980-1-1# ls -led /ifs/posix-delete_child
drwxrwxrwx +   2 root  wheel  0 Jun 18 14:20 /ifs/posix-delete_child
 OWNER: user:root
 GROUP: group:wheel
 0: user:root allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
 1: group:wheel allow dir_gen_read,dir_gen_write,dir_gen_execute,delete_child
 2: everyone allow dir_gen_read,dir_gen_write,dir_gen_execute,delete_child

También es posible actualizar el kernel de Linux para revertir el comportamiento. Esto requiere la compilación del kernel de Linux desde el código fuente después de la actualización fs/nfs/dir.c Para quitar el NFS4_ACCESS_DELETE requisito de la NFS_MAY_WRITE macro.

Antes:

#define NFS_MAY_WRITE (NFS4_ACCESS_MODIFY | \
		NFS4_ACCESS_EXTEND | \
		NFS4_ACCESS_DELETE)

Después:

#define NFS_MAY_WRITE (NFS4_ACCESS_MODIFY | \
		NFS4_ACCESS_EXTEND)