OneFS : La mise à jour du noyau Linux vers NFS provoque des échecs d’appel « access »

Après une mise à niveau du noyau Linux, les vérifications d’accès qui réussissaient auparavant échouent désormais sur les répertoires dans lesquels l’utilisateur accédant ne dispose pas d’autorisations « delete_child » sur un répertoire impliqué dans son workflow. Cela peut être validé à l’aide de Linux test avec la commande -w flag par rapport à ce même répertoire ; Sur les anciennes versions du noyau, le code de retour de cette commande est 0 alors que dans les noyaux plus récents, il est 1.

Cela a un impact sur les clients Red Hat et Centos qui passent de la version 7 à des versions plus récentes.

Ce changement de comportement a été introduit dans le noyau principal Linux v4.13-rc2 lors d’une refactorisation du code du pilote NFS. Cependant, apparemment, la vérification était présente à partir du noyau principal v3.7-rc1, et n’était pas correctement appelée.

Après un examen approfondi, nous pensons que le nouveau comportement du noyau Linux et le nôtre sont corrects. Le linux test command et access Les appels système sont tous deux basés sur la norme POSIX, qui conceptualise uniquement :

• LIRE
• ÉCRIRE
• EXÉCUTER

Attendu que selon rfc1813#section-3.3.4 et rfc7530#section-16.1 ; NFS permet des autorisations plus granulaires et conceptualise donc les éléments suivants :

• LIRE
• MODIFIER
• AJOUTER
• SUPPRIMER
• EXÉCUTER

L’autorisation DELETE étant définie comme si un client peut : Delete an existing directory entry. Cela correspond directement à delete_child dans OneFS, et doit être refusé dans les cas où le client ne dispose pas de cette autorisation. Remarquez également ; Les autorisations POSIX et NFS ne correspondent pas exactement. POSIX WRITE inclut tous les concepts des autorisations NFS MODIFY, APPEND et DELETE distinctes. Ainsi, lorsqu’un outil POSIX tente de vérifier les autorisations « WRITE », le noyau Linux traduit cette demande de « WRITE » en « MODIFY and APPEND and DELETE »

Enfin, le comportement le plus récent est plus conforme à celui des autres pilotes du système de fichiers Linux qui prennent également en charge cet ensemble d’autorisations. Par exemple, un test par rapport à un serveur SMB avec le même jeu d’autorisations renvoie également un échec lors de la vérification de l’écriture POSIX avec l’option test à l’aide de la commande -w drapeau.
 

# 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

Les comportements OneFS et Linux dans cette circonstance sont corrects, car les workflows affectés par ce problème doivent fournir la delete_child Autorisation accordée aux utilisateurs et groupes concernés. Par exemple, si un répertoire fournit un accès complet à son utilisateur propriétaire et à son groupe, mais supprime delete_child à partir de l’autorisation everyone, ils peuvent soit ajouter cette autorisation à everyone, soit ajouter une entrée de contrôle d’accès (ACE) supplémentaire pour l’utilisateur ou le groupe qui rencontre des problèmes à la liste de contrôle d’accès (ACL) de directement.

# 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

Il est également possible de mettre à jour le noyau Linux pour rétablir le comportement. Cela nécessite de créer le noyau Linux à partir des sources après la mise à jour fs/nfs/dir.c Pour supprimer le NFS4_ACCESS_DELETE exigence de l' NFS_MAY_WRITE macro.

Avant :

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

Après :

#define NFS_MAY_WRITE (NFS4_ACCESS_MODIFY | \
		NFS4_ACCESS_EXTEND)