Grundlegendes zu Modusbits in Azure NetApp-Dateien
Dateizugriffsberechtigungen in NFS beschränken, was Benutzer und Gruppen tun können, sobald ein NAS-Volume bereitgestellt wurde. Modusbits sind ein wichtiges Feature von NFS-Dateiberechtigungen in Azure NetApp Files.
NFS-Modusbits
Bitberechtigungen im Modus in NFS bieten grundlegende Berechtigungen für Dateien und Ordner mithilfe einer standardmäßigen numerischen Darstellung von Zugriffssteuerelementen. Modusbits können entweder mit NFSv3 oder NFSv4.1 verwendet werden, aber Modusbits sind die Standardoption zum Sichern von NFSv3 gemäß RFC-1813. In der folgenden Tabelle wird gezeigt, wie diese numerischen Werte Zugriffssteuerelementen entsprechen.
| Modus bit numerisch |
|---|
| 1 – Ausführen (x) |
| 2 – Schreiben (w) |
| 3 – Schreiben/Ausführen (wx) |
| 4 – lesen (r) |
| 5 – Lese-/Ausführung (rx) |
| 6 – Lese-/Schreibzugriff (rw) |
| 7 – Lese-/Schreibzugriff/Execute (rwx) |
Numerische Werte werden auf verschiedene Segmente einer Zugriffssteuerung angewendet: Besitzer, Gruppe und alle anderen, was bedeutet, dass keine präzisen Benutzerzugriffssteuerelemente für die Basis-NFSv3 vorhanden sind. Die folgende Abbildung zeigt ein Beispiel dafür, wie eine Bitzugriffssteuerung für den Modus für die Verwendung mit einem NFSv3-Objekt erstellt werden kann.
Azure NetApp Files unterstützt keine POSIX ACLs. Daher sind granulare ACLs nur bei NFSv3 möglich, wenn sie ein NTFS-Sicherheitsformatvolume mit gültigen UNIX-zu-Windows-Namenszuordnungen über einen Namendienst wie Active Directory LDAP verwenden. Alternativ können Sie NFSv4.1 mit Azure NetApp Files und NFSv4.1 ACLs verwenden.
In der folgenden Tabelle wird die Berechtigungs granularität zwischen NFSv3-Modusbits und NFSv4.x ACLs verglichen.
| NFSv3-Modusbits | NFSv4.x ACLs |
|---|---|
|
|
Weitere Informationen finden Sie unter "Grundlegendes zu NFSv4.x"-Zugriffssteuerungslisten acLs.
Sticky bits, setuid, and setgid
Bei Verwendung von Modusbits mit NFS-Bereitstellungen basiert der Besitz von Dateien und Ordnern auf dem uid Benutzer, gid der die Dateien und Ordner erstellt hat. Wenn ein Prozess ausgeführt wird, wird er als Der Benutzer ausgeführt, der ihn gestartet hat, und verfügt daher über die entsprechenden Berechtigungen. Mit speziellen Berechtigungen (z setuid. B. , setgidsticky bit) kann dieses Verhalten gesteuert werden.
Setuid
Das setuid Bit wird durch ein "s" im Ausführungsbereich des Besitzers bits einer Berechtigung festgelegt. Das setuid Bit ermöglicht die Ausführung einer ausführbaren Datei als Besitzer der Datei und nicht als Benutzer, der versucht, die Datei auszuführen. Die Anwendung hat beispielsweise /bin/passwd standardmäßig das setuid Bit aktiviert, daher wird die Anwendung als Stamm ausgeführt, wenn ein Benutzer versucht, sein Kennwort zu ändern.
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
Wenn das setuid Bit entfernt wird, funktioniert die Kennwortänderungsfunktion nicht ordnungsgemäß.
# ls -la /bin/passwd
-rwxr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password:
New password:
Retype new password:
passwd: Authentication token manipulation error
passwd: password unchanged
Wenn das setuid Bit wiederhergestellt wird, wird die passwd-Anwendung als Besitzer (Stamm) ausgeführt und funktioniert ordnungsgemäß, aber nur für den Benutzer, der den Passwd-Befehl ausführt.
# chmod u+s /bin/passwd
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
# su user2
user2@parisi-ubuntu:/mnt$ passwd user1
passwd: You may not view or modify password information for user1.
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password:
New password:
Retype new password:
passwd: password updated successfully
Setuid hat keine Auswirkungen auf Verzeichnisse.
Setgid
Das setgid Bit kann sowohl für Dateien als auch für Verzeichnisse verwendet werden.
Mit Verzeichnissen kann setgid als Möglichkeit verwendet werden, die Besitzergruppe für Dateien und Ordner zu erben, die unter dem übergeordneten Verzeichnis mit dem Bitsatz erstellt wurden. Wie setuidfolgt, wird das ausführbare Bit in "s" oder "S" geändert.
Hinweis
Capital "S" bedeutet, dass das ausführbare Bit nicht festgelegt wurde, z. B. wenn die Berechtigungen für das Verzeichnis "6" oder "rw" sind.
Beispiel:
# chmod g+s testdir
# ls -la | grep testdir
drwxrwSrw- 2 user1 group1 4096 Oct 11 16:34 testdir
# who
root ttyS0 2023-10-11 16:28
# touch testdir/file
# ls -la testdir
total 8
drwxrwSrw- 2 user1 group1 4096 Oct 11 17:09 .
drwxrwxrwx 5 root root 4096 Oct 11 16:37 ..
-rw-r--r-- 1 root group1 0 Oct 11 17:09 file
Bei Dateien verhält sich "setgid" ähnlich wie setuidbei ausführbaren Dateien, die mithilfe der Gruppenberechtigungen des Gruppenbesitzers ausgeführt werden. Wenn sich ein Benutzer in der Besitzergruppe befindet, hat dieser Benutzer Zugriff, um die ausführbare Datei auszuführen, wenn setgid festgelegt ist. Wenn sie sich nicht in der Gruppe befinden, erhalten sie keinen Zugriff. Wenn ein Administrator beispielsweise einschränken möchte, welche Benutzer den mkdir Befehl auf einem Client ausführen können, können sie setgid verwenden.
/bin/mkdir Normalerweise verfügt sie über 755 Berechtigungen mit Stammbesitz. Dies bedeutet, dass jeder auf einem Client ausgeführt werden mkdir kann.
# ls -la /bin/mkdir
-rwxr-xr-x 1 root root 88408 Sep 5 2019 /bin/mkdir
Um das Verhalten zu ändern, um zu begrenzen, welches Benutzer den mkdir Befehl ausführen können, ändern Sie die Gruppe, die die mkdir Anwendung besitzt, ändern Sie die Berechtigungen für /bin/mkdir 750, und fügen Sie dann das setgid-Bit zu mkdir.
# chgrp group1 /bin/mkdir
# chmod g+s /bin/mkdir
# chmod 750 /bin/mkdir
# ls -la /bin/mkdir
-rwxr-s--- 1 root group1 88408 Sep 5 2019 /bin/mkdir
Daher wird die Anwendung mit Berechtigungen für group1. Wenn der Benutzer kein Mitglied group1ist, erhält der Benutzer keinen Zugriff auf die Ausführung mkdir.
User1 ist Mitglied von group1, ist aber user2 nicht:
# id user1
uid=1001(user1) gid=1001(group1) groups=1001(group1)
# id user2
uid=1002(user2) gid=2002(group2) groups=2002(group2)
Nach dieser Änderung kann ausgeführt werden, user1 kann aber user2 nicht mehr ausgeführt mkdirwerden, da user2 sie nicht vorhanden group1ist.
# su user1
$ mkdir test
$ ls -la | grep test
drwxr-xr-x 2 user1 group1 4096 Oct 11 18:48 test
# su user2
$ mkdir user2-test
bash: /usr/bin/mkdir: Permission denied
Sticky Bit
Das Sticky-Bit wird nur für Verzeichnisse verwendet und steuert bei Verwendung, welche Dateien unabhängig von ihren Bitberechtigungen im Modus in diesem Verzeichnis geändert werden können. Wenn ein Sticky-Bit festgelegt ist, können nur Dateibesitzer (und Stamm) Dateien ändern, auch wenn Dateiberechtigungen als "777" angezeigt werden.
Im folgenden Beispiel befindet sich das Verzeichnis "Sticky" in einem Azure NetApp Fils-Volume und verfügt über breite offene Berechtigungen, aber das Sticky-Bit ist festgelegt.
# mkdir sticky
# chmod 777 sticky
# chmod o+t sticky
# ls -la | grep sticky
drwxrwxrwt 2 root root 4096 Oct 11 19:24 sticky
Innerhalb des Ordners befinden sich Dateien im Besitz verschiedener Benutzer. Alle verfügen über 777 Berechtigungen.
# ls -la
total 8
drwxrwxrwt 2 root root 4096 Oct 11 19:29 .
drwxrwxrwx 8 root root 4096 Oct 11 19:24 ..
-rwxr-xr-x 1 user2 group1 0 Oct 11 19:29 4913
-rwxrwxrwx 1 UNIXuser group1 40 Oct 11 19:28 UNIX-file
-rwxrwxrwx 1 user1 group1 33 Oct 11 19:27 user1-file
-rwxrwxrwx 1 user2 group1 34 Oct 11 19:27 user2-file
Normalerweise kann jeder diese Dateien ändern oder löschen. Da der übergeordnete Ordner jedoch einen Sticky-Bit-Satz aufweist, können nur die Dateibesitzer Änderungen an den Dateien vornehmen.
Benutzer1 kann z. B. weder ändern noch löschen user2-file:
# su user1
$ vi user2-file
Only user2 can modify this file.
Hi
~
"user2-file"
"user2-file" E212: Can't open file for writing
$ rm user2-file
rm: can't remove 'user2-file': Operation not permitted
Umgekehrt können Sie die Datei nicht ändern oder löschenuser1-file, user2 da sie nicht über die Datei verfügen und das Sticky-Bit im übergeordneten Verzeichnis festgelegt ist.
# su user2
$ vi user1-file
Only user1 can modify this file.
Hi
~
"user1-file"
"user1-file" E212: Can't open file for writing
$ rm user1-file
rm: can't remove 'user1-file': Operation not permitted
Der Stamm kann die Dateien jedoch weiterhin entfernen.
# rm UNIX-file
Um die Fähigkeit des Stamms zum Ändern von Dateien zu ändern, müssen Sie den Stamm in einem anderen Benutzer über eine Exportrichtlinienregel für Azure NetApp-Dateien squashen. Weitere Informationen finden Sie im Stamm squashen ing.
Umask
In NFS-Vorgängen können Berechtigungen über Modusbits gesteuert werden, die numerische Attribute nutzen, um den Datei- und Ordnerzugriff zu bestimmen. Diese Modusbits bestimmen Lese-, Schreib-, Ausführungs- und spezielle Attribute. Numerisch werden Berechtigungen wie folgt dargestellt:
- Execute = 1
- Lesen = 2
- Write = 4
Gesamtberechtigungen werden durch Hinzufügen oder Subtrahieren einer Kombination aus dem vorherigen bestimmt. Beispiel:
- 4 + 2 + 1 = 7 (kann alles tun)
- 4 + 2 = 6 (Lese-/Schreibzugriff)
Weitere Informationen finden Sie in der UNIX-Berechtigungshilfe.
Umask ist eine Funktion, mit der ein Administrator die Berechtigungsstufe für einen Client einschränken kann. Standardmäßig ist der Umask für die meisten Clients auf 0022 festgelegt. 0022 bedeutet, dass Dateien, die von diesem Client erstellt wurden, diesem Umask zugewiesen werden. Der Umask wird von den Basisberechtigungen des Objekts subtrahiert. Wenn ein Volume über 0777 Berechtigungen verfügt und mit NFS auf einem Client mit einem Umask von 0022 bereitgestellt wird, verfügen Objekte, die vom Client auf dieses Volume geschrieben wurden, über 0755 Zugriff (0777 – 0022).
# umask
0022
# umask -S
u=rwx,g=rx,o=rx
Viele Betriebssysteme lassen jedoch nicht zu, dass Dateien mit Ausführungsberechtigungen erstellt werden, aber sie ermöglichen Ordnern die richtigen Berechtigungen. Daher können Dateien, die mit einem Umask von 0022 erstellt wurden, mit Berechtigungen von 0644 enden. Im folgenden Beispiel wird RHEL 6.5 verwendet:
# umask
0022
# cd /cdot
# mkdir umask_dir
# ls -la | grep umask_dir
drwxr-xr-x. 2 root root 4096 Apr 23 14:39 umask_dir
# touch umask_file
# ls -la | grep umask_file
-rw-r--r--. 1 root root 0 Apr 23 14:39 umask_file