Wie funktionieren Dateiberechtigungen / -attribute? Kernel-Level, FS-Level oder beides?


8

Eine Frage, die mir früher eingefallen ist: Sind Dateiberechtigungen / -attribute vom Betriebssystem (und damit vom Kernel) abhängig oder sind sie vom Dateisystem abhängig? Es scheint mir, dass die zweite Alternative die logischere ist, aber ich habe noch nie von reiserfsDateiberechtigungen gehört, zum Beispiel: nur "Unix-Dateiberechtigungen". Um aus einem Wikipedia-Artikel zu zitieren :

Als neue Windows-Versionen herauskamen, hat Microsoft das Inventar der verfügbaren Attribute im NTFS-Dateisystem erweitert

Dies scheint darauf hinzudeuten, dass Windows-Dateiattribute irgendwie an das Dateisystem gebunden sind.

Kann mich bitte jemand aufklären?

Antworten:


7

Sowohl der Kernel als auch das Dateisystem spielen eine Rolle. Berechtigungen werden im Dateisystem gespeichert, daher muss ein Speicherort für die Informationen im Dateisystemformat vorhanden sein. Berechtigungen werden vom Kernel erzwungen und an Anwendungen übermittelt. Daher muss der Kernel Regeln implementieren, um zu bestimmen, was die im Dateisystem gespeicherten Informationen bedeuten.

"Unix-Dateiberechtigungen" beziehen sich auf ein herkömmliches Berechtigungssystem, das drei Aktionen (Lesen, Schreiben, Ausführen) umfasst, die über drei Rollentypen (Benutzer, Gruppe, andere) gesteuert werden. Die Aufgabe des Dateisystems besteht darin, 3 × 3 = 9 Informationsbits zu speichern. Die Aufgabe des Kernels besteht darin, diese Bits als Berechtigungen zu interpretieren. Insbesondere wenn ein Prozess eine Operation für eine Datei versucht, muss der Kernel unter Berücksichtigung des Benutzers und der Gruppen, unter denen der Prozess ausgeführt wird, die Berechtigungsbits der Datei und die angeforderte Operation bestimmen, ob die Operation zugelassen werden soll. ("Unix-Dateiberechtigungen" enthalten normalerweise auch setuid- und setgid-Bits , die streng genommen keine Berechtigungen sind.)

Moderne Unix-Systeme unterstützen möglicherweise andere Arten von Berechtigungen. Die meisten modernen Unix-Systeme (Solaris, Linux, * BSD) unterstützen Zugriffssteuerungslisten, mit denen Lese- / Schreib- / Ausführungsberechtigungen für mehr als einen Benutzer und mehr als eine Gruppe für jede Datei zugewiesen werden können. Das Dateisystem muss Platz zum Speichern dieser zusätzlichen Informationen haben, und der Kernel muss Code zum Nachschlagen und Verwenden dieser Informationen enthalten. Ext2, reiserfs, btrfs, zfs und die meisten anderen modernen Unix-Dateisystemformate definieren einen Ort zum Speichern solcher ACLs. Mac OS X unterstützt einen anderen Satz von ACLs, die nicht traditionelle Berechtigungen wie "Anhängen" und "Unterverzeichnis erstellen" enthalten. Das HFS + -Dateisystemformat unterstützt sie. Wenn Sie ein HFS + -Volume unter Linux bereitstellen, werden diese ACLs nicht erzwungen, da der Linux-Kernel sie nicht unterstützt.

Umgekehrt gibt es Betriebssysteme und Dateisysteme, die die Zugriffskontrolle nicht unterstützen. Beispielsweise wurden FAT und Varianten für Einzelbenutzer-Betriebssysteme und Wechselmedien entwickelt, und ihre Berechtigungen sind auf Lesen / Lesen-Schreiben und Verstecken / Sichtbar beschränkt. Dies sind die von DOS erzwungenen Berechtigungen . Wenn Sie ein ext2-Dateisystem unter DOS bereitstellen, werden die ext2-Berechtigungen nicht erzwungen. Wenn Sie dagegen unter Linux auf ein FAT-Dateisystem zugreifen, haben alle Dateien die gleichen Berechtigungen.

Aufeinanderfolgende Windows-Versionen bieten Unterstützung für weitere Berechtigungstypen. Das NTFS-Dateisystem wurde erweitert, um diese zusätzlichen Berechtigungen zu speichern. Wenn Sie auf ein Dateisystem mit den neueren Berechtigungen eines älteren Betriebssystems zugreifen, kennt das Betriebssystem diese neueren Berechtigungen nicht und erzwingt sie daher nicht. Wenn Sie dagegen mit einem neueren Betriebssystem auf ein älteres Dateisystem zugreifen, enthält es keine neuen Berechtigungen, und es ist Sache des Betriebssystems, sinnvolle Fallbacks bereitzustellen.


"Die Aufgabe des Kernels besteht darin, diese Bits als Berechtigungen zu interpretieren. Insbesondere wenn ein Prozess eine Operation für eine Datei versucht, muss der Kernel bestimmen, [...]" bedeutet dies nicht, dass ein Kernel theoretisch geändert werden könnte all das ignorieren und trotzdem die Daten lesen? (Eine Art direkter Datenträgerzugriff) Oder verhindert etwas anderes das?
Overmind

@ Overmind Natürlich. Kernel-Code hat Zugriff auf alles. Die Festplatte weiß nichts über Prozesse, Benutzer oder Berechtigungen. Der Kernel teilt der Festplatte mit, dass sie mir Block 232876 geben soll, und die Festplatte antwortet mit dem Inhalt des Blocks. Das Bestimmen, welche Prozesse auf welche Blöcke (oder welche Teile von Blöcken) zugreifen dürfen, ist Aufgabe des Kernels.
Gilles 'SO - hör auf böse zu sein'

4

Um bestimmte Rechte nutzen zu können, müssen sowohl der Kernel als auch das Dateisystem diese unterstützen. Wenn das Dateisystem nicht einmal die grundlegendsten Zugriffsrechte unterstützt, muss der Dateisystemcode diese fälschen (z. B. mit der Mount-Option umaskfür vfat).


3

Mein Verständnis ist, dass der Kernel Inodes in VFS implementiert. Inodes enthalten Berechtigungsinformationen (UNIX und ACL) sowie andere Metadaten, und das Dateisystem kann den Inode erweitern, um Funktionen hinzuzufügen. Wenn Sie interessiert sind, informieren Sie sich über Linux VFS - wenn Sie kein Systemprogrammierer sind.


1

In der Regel werden Dateiberechtigungen und Dateiattribute im Dateisystem gespeichert [der genaue Weg hängt vom jeweiligen Dateisystem ab (ext3 / 4, Riser, NTFS usw.)], werden jedoch vom Kernel verwendet, um normalerweise etwas zu erzwingen .

Zum Beispiel ist der Kernel in * nix wie sistema "das Ding", das die Bedeutung der UID kennt, die einer Datei / einem Verzeichnis zugeordnet ist. Eine Datei-UID ist einfach eine Nummer, die vom Dateisystem neben einer Certan-Datei gespeichert wird, aber die "Übersetzung" dieser Nummer an einen bestimmten Benutzer (und die entsprechenden Rechte, etwas zu tun oder nicht) wird vom Kernel vorgenommen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.