Deutsch

Entwicklertools · Chmod-Rechner

Das Unix-Berechtigungsmodell: vom chmod der 1970er Jahre zu POSIX-Modusbits

· Hintergrund

chmod Unix Zugriffskontrolle

das traditionelle Modusmodell, dargestellt als eindeutiges Unix-Berechtigungsbitdiagramm
Original-ToolAcre-Vektorillustration

Das Modell „owner/group/others“ hat Jahrzehnte mit bemerkenswert wenigen Änderungen überlebt. In diesem Beitrag geht es darum, woher es kommt, was POSIX standardisiert hat und warum es immer noch für die meisten Jobs geeignet ist.

Ein Design aus den 1970er Jahren in Ihrer 2020er-Bereitstellung – jeder Container und CI-Runner spricht immer noch rwx, und es hilft zu wissen, warum

Aktuelle Bereitstellungen enthalten immer noch Modi wie 0644 und symbolische Zeichenfolgen wie rw-r--r--, aber dieses Repository ist kein historisches Archiv. Sein Beweis ist die implementierte Darstellung: zwölf Bits, deterministische Konvertierung und Validierung oktaler und symbolischer Eingaben. Daten, Erfinder, Patente und Behauptungen zu jedem von Unix abgeleiteten System erfordern Quellen, die hier nicht angegeben werden.

Der Rechner bietet daher eine Gegenwartsansicht eines kompakten Berechtigungsmodells. Eine Ganzzahl steuert Eigentümer, Gruppe und andere Steuerelemente sowie Setuid, Setgid und Sticky. Die Ausgabe kann in oktaler, symbolischer und Matrixform überprüft werden. Die Übereinstimmung beweist eine konsistente Konvertierung, nicht den Ursprung, die Universalität oder die Durchsetzung des Modells.

Eine langlebige Notation erscheint in aktuellen Bereitstellungen, aber dieses Repository ist keine Verlaufsquelle

Neun gewöhnliche Bits bilden drei gleiche Klassen. Besitzer, Gruppe und andere erhalten jeweils Lese-, Schreib- und Ausführungspositionen mit den Gewichtungen 4, 2 und 1. Der Rechner behält diese Reihenfolge überall bei: in den abschließenden drei Oktalziffern, der neunstelligen symbolischen Zeile, der Kontrollkästchenmatrix und der für eine Datei oder ein Verzeichnis generierten Klartextbeschreibung.

Ein Modus von 640 demonstriert die Struktur ohne Abstammungsanspruch. Besitzer 6 bedeutet Lesen und Schreiben, Gruppe 4 bedeutet Lesen und andere 0 bedeuten keine gewöhnlichen Berechtigungen, was rw-r----- erzeugt. Wie Artikel 501 erklärt, handelt es sich hierbei um berechenbare Flags; Die Identifizierung des tatsächlichen Eigentümers, der Gruppe oder des Prozesses bleibt außerhalb der Konvertierung.

Das implementierte Modell verfügt über neun gewöhnliche Bits in drei Klassen

Setuid ist als 4000-Maske implementiert. In einer regulären Datei platziert der Renderer s an der Owner-Execute-Position, wenn sowohl setuid als auch Owner-Execute vorhanden sind. Wenn setuid vorhanden ist, ohne dass der Eigentümer ausführt, wird stattdessen S dort platziert, wobei der wichtige Unterschied zwischen einem Spezialbit und dem darunter liegenden gewöhnlichen Ausführungsbit erhalten bleibt.

Die Dateibeschreibung erklärt die Kleinschreibung als Ausführung mit der Identität des Dateieigentümers und kennzeichnet die Großbuchstabenkombination als nicht auszuführende Kombination. Diese Anweisungen beschreiben die Ausgabe dieser Implementierung. Das Repositorium liefert keine Patentaufzeichnungen oder Primärhistorien, daher wird in diesem Abschnitt weder der Mechanismus noch das Datum seiner Einführung genannt.

setuid-Verhalten ist implementiert; Die Patenthistorie wird nicht beschafft

Verzeichniserklärungen verwenden denselben numerischen Wert, aber unterschiedliche Verben für gewöhnliche Bits. Listeneinträge lesen, Cover schreiben, Einträge erstellen, umbenennen und löschen sowie Cover ausführen, die in das Verzeichnis eingeben und benannte Inhalte erreichen. Die Implementierung beschreibt außerdem, dass setgid für ein Verzeichnis dazu führt, dass neu erstellte Dateien die Gruppe dieses Verzeichnisses erben.

Sticky wird durch 1000 dargestellt und belegt die andere Ausführungsposition als t oder T. Für ein Verzeichnis beschreibt das Tool das eingeschränkte Löschen für freigegebene Einträge. Hierbei handelt es sich um implementierte Semantiken, die vom Rechner präsentiert werden. Es wird kein Verzweigungsverlauf oder eine systemübergreifende Abstammung erstellt und es wird kein Live-Dateisystem abgefragt, um das lokale Verhalten zu bestätigen.

Das Verhalten des Verzeichnis-Spezialbits wird ohne Herkunftsanspruch beschrieben

Die Quelle benennt jede Maske direkt: 0400, 0200 und 0100 für den Besitzer; 0040, 0020 und 0010 für Gruppe; 0004, 0002 und 0001 für andere. Setuid, setgid und sticky fügen 4000, 2000 und 1000 hinzu. Bei der Konvertierung handelt es sich eher um Bittests und bitweise Kombinationen als um die Berufung auf einen externen Standard.

Eingaberegeln sind ähnlich konkret. Oktal akzeptiert ein bis vier Ziffern von 0 bis 7, optional mit führenden Formen im 0- oder 0o-Stil. Die symbolische Eingabe akzeptiert neun Positionen oder zehn mit einem erkannten Dateitypzeichen. Das Repository legt nicht fest, dass jede Implementierung oder jeder Standard genau dieselbe Oberflächengrammatik akzeptiert.

Benannte Bitmasken und Konvertierungssemantik werden überprüft; Ansprüche auf universelle Standards gelten nicht

Das Kompaktmodell hat bewusste Grenzen. Es stellt eine Besitzerklasse, eine Gruppenklasse und eine weitere Klasse bereit, aber keinen Named-User-Eintrag, Named-Group-Eintrag, ACL-Maske oder Standard-ACL. Es ist auch kein Fähigkeitssatz vorhanden. Diese Mechanismen können nicht aus einem scheinbar gewöhnlichen rwx-String oder einer erfolgreichen Oktalkonvertierung abgeleitet werden.

Die Befehlsgenerierung erweitert das Modell nicht. Es gibt ein oktales Argument oder explizite u=-, g=- und o=-Klauseln aus und fügt bei Bedarf u+s, g+s oder +t hinzu. Das Ergebnis bleibt der angezeigte Text. Bei einer verantwortungsvollen Überprüfung werden alle ACL-, Fähigkeits-, Eigentums- und Durchsetzungsnachweise separat erfasst, bevor der Modus als vollständiges Zugriffskontrollkonto behandelt wird.

ACLs und Funktionen liegen außerhalb des implementierten Modusmodells

Dieser Quellsatz enthält keinen unterstützten Vergleich mit Windows, VMS, Plan 9 oder anderen Betriebssystem-Berechtigungsverläufen. Das Weglassen dieser Erzählungen ist zutreffender, als erinnerte Gegensätze als Tatsachen darzustellen. Der Rechner demonstriert nur die von ihm implementierte Modusdarstellung und seine Tests können das Konvertierungsverhalten und nicht die Entwicklung unabhängiger Systeme ermitteln.

Die gleiche Vorsicht gilt für die breite Kompatibilitätssprache. Ein erkanntes führendes Dateitypzeichen kann vor den neun Berechtigungspositionen analysiert werden, dies beweist jedoch keine universelle ls-Formatierung. Nutzen Sie die Ausgabe als präzise Lektüre der akzeptierten Notation dieses Tools und konsultieren Sie dann die maßgebliche Plattformdokumentation für Verhaltensweisen außerhalb dieser quellengestützten Grenzen.

Andere Betriebssystem-Berechtigungsverläufe werden ohne Quellen weggelassen

Was hier der Prüfung standhält, ist die Kompaktheit des implementierten Modells. Zwölf benannte Bits decken drei gewöhnliche Berechtigungsklassen und drei spezielle Flags ab, während oktale und symbolische Ansichten dieselbe Ganzzahl in unterschiedlichen Formen offenlegen. Ungültige Ziffern oder falsch platzierte symbolische Buchstaben werden abgelehnt und nicht stillschweigend repariert, wodurch Fehler bei der Konvertierung sichtbar werden.

Das reicht für einen praktischen Imbiss ohne Geschichtsstunde. Dekodieren Sie den Modus, überprüfen Sie jede Klasse und stellen Sie fest, ob s, S, t oder T eine Ausführungsposition ersetzt. Dann hören Sie dort auf, wo die Beweise aufhören: Der Rechner erklärt die Darstellung und den generierten Text, während Eigentum, Richtlinien, Dateisystemverhalten und historische Herkunft andere Quellen erfordern.