OneFS: Linux-Kernel-Update auf NFS führt zu Fehlern bei "Zugriffs"-Aufrufen

Nach einem Upgrade des Linux-Kernels schlagen zuvor erfolgreiche Zugriffsprüfungen nun für Verzeichnisse fehl, in denen der zugreifende Nutzer keine "delete_child"-Berechtigungen für ein Verzeichnis hat, das an seinem Workflow beteiligt ist. Dies kann mithilfe von Linux validiert werden test Befehl mit dem Befehl -w flag für dasselbe Verzeichnis; Bei alten Kernel-Versionen lautet der Rückgabecode von diesem Befehl 0 während es in neueren Kernels 1.

Dies wirkt sich auf Red Hat- und Centos-Clients aus, die von Version 7 auf neuere Versionen umsteigen.

Diese Verhaltensänderung wurde im Linux-Mainline-Kernel v4.13-rc2 während einer Überarbeitung des NFS-Treibercodes eingeführt. Anscheinend war die Prüfung jedoch ab Mainline-Kernel v3.7-rc1 vorhanden und wurde nicht korrekt aufgerufen.

Nach eingehender Prüfung sind wir der Meinung, dass sowohl das Verhalten des neuen Linux-Kernels als auch unser Verhalten korrekt sind. Die Linux test Befehl und access Systemaufrufe basieren beide auf dem POSIX-Standard, der nur Folgendes konzeptualisiert:

• LESEN
• SCHREIBEN
• AUSFÜHREN

Gemäß rfc1813#section-3.3.4 und rfc7530#section-16.1; NFS ermöglicht granularere Berechtigungen und konzeptualisiert daher Folgendes:

• LESEN
• MODIFIZIEREN
• ANFÜGEN
• LÖSCHEN
• AUSFÜHREN

Mit der DELETE-Berechtigung, die so definiert wird, ob ein Client Delete an existing directory entry. Dies entspricht direkt delete_child in OneFS und sollte verweigert werden, wenn der Client nicht über diese Berechtigung verfügt. Beachten Sie auch; POSIX- und NFS-Berechtigungen stimmen nicht genau überein. POSIX WRITE enthält alle Konzepte in den separaten NFS-BERECHTIGUNGEN MODIFY, APPEND und DELETE. Wenn also ein POSIX-Tool versucht, die "WRITE"-Berechtigungen zu überprüfen, übersetzt der Linux-Kernel diese Anfrage für "WRITE" in "MODIFY and APPEND and DELETE"

Schließlich entspricht das neuere Verhalten eher anderen Linux-Dateisystemtreibern, die diesen Berechtigungssatz ebenfalls unterstützen. Wenn Sie beispielsweise mit einem SMB-Filer mit demselben Berechtigungssatz testen, wird auch ein Fehler zurückgegeben, wenn POSIX WRITE mit dem test Befehl mit dem Befehl -w Flagge.
 

# 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

Sowohl das OneFS- als auch das Linux-Verhalten sind unter diesen Umständen korrekt, da solche Workflows, die von diesem Problem betroffen sind, die delete_child Betroffenen Nutzern und Gruppen zur Verfügung zu stellen. Beispiel: Wenn ein Verzeichnis dem Eigentümernutzer und der Eigentümergruppe Vollzugriff gewährt, aber delete_child Über die Berechtigung "Jeder" können sie diese Berechtigung entweder "Jeder" hinzufügen, oder sie können einen zusätzlichen Zugriffskontrolleintrag (Access Control Entry, ACE) für den Nutzer oder die Gruppe, bei dem Probleme auftreten, direkt zur Zugriffskontrollliste (ACL) hinzufügen.

# 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

Es ist auch möglich, den Linux-Kernel zu aktualisieren, um das Verhalten rückgängig zu machen. Dazu muss der Linux-Kernel nach der Aktualisierung aus dem Quellcode erstellt werden fs/nfs/dir.c So entfernen Sie die NFS4_ACCESS_DELETE Anforderung der NFS_MAY_WRITE Makro.

Vorher:

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

Nachher:

#define NFS_MAY_WRITE (NFS4_ACCESS_MODIFY | \
		NFS4_ACCESS_EXTEND)