Entwicklertools · Chmod-Rechner
POSIX-ACLs vs. chmod-Modusbits: wenn rwx nicht ausreicht
· Hintergrund
chmod Unix Zugriffskontrolle
Modusbits decken einen Besitzer, eine Gruppe und alle anderen ab. In diesem Beitrag wird das POSIX.1e-ACL-Modell erläutert, das die Lücke füllt, wie es mit chmod interagiert und wann eine gemeinsam genutzte Gruppe immer noch die einfachere Antwort ist.
Ein Leser mehr, als das Modell zulässt – eine Datei gehört zur App-Gruppe und ein Prüfer außerhalb der Gruppe muss sie lesen
Das Normalmodusmodell verfügt über keinen vierten Identitätssteckplatz. Es kann Berechtigungen für einen Besitzer, eine Gruppe und alle anderen beschreiben, aber keinen zusätzlichen Prüfer benennen. Der Rechner spiegelt diese Grenze genau wider: Seine Matrix, die symbolische Anzeige und die Zusammenfassungen legen diese drei Klassen plus Sonderbits offen, nicht Zugriffseinträge pro Benutzer oder pro Gruppe.
Die Erweiterung der anderen Klasse, nur um einen zusätzlichen Leser aufzunehmen, würde sich auf jede Identität auswirken, die in diese Klasse fällt. Der Rechner kann diese arithmetische Änderung anzeigen, z. B. den Wechsel von 0640 zu 0644, aber er kann nicht entscheiden, ob ein breiterer Zugriff akzeptabel ist. Der benannte Zugang erfordert Beweise und Werkzeuge außerhalb dieser Route.
Die Grenze von drei Klassen – warum das traditionelle Modell jeweils genau einen Slot für Besitzer, Gruppe und andere hat
Jede abschließende Oktalziffer gehört zu einer festen Klasse. Besitzer, Gruppe und andere erhalten Lese-, Schreib- und Ausführungsflags, wodurch neun normale Positionen entstehen. Das Modell kann für eine benannte Person kein weiteres Tripel einfügen. Eine erfolgreiche Konvertierung beschreibt daher den Basismodus originalgetreu, sagt aber nichts über an anderer Stelle angehängte zusätzliche Einträge aus.
Diese Einschränkung ist wichtig, wenn scheinbar restriktive Ausgaben gelesen werden. Ein symbolischer Wert von rw-r----- gibt Ihnen den Basisbesitzer, die Gruppe und andere durch 0640 dargestellte Bits an. Es beweist nicht, dass keine andere Identität das Objekt lesen kann, da der Rechner weder ACL-Daten prüft noch eine externe Durchsetzungsebene beachtet.
POSIX.1e-ACLs – benannte Benutzer- und benannte Gruppeneinträge, die derselben Datei hinzugefügt, mit setfacl festgelegt und mit getfacl gelesen werden
Benannte Benutzer- und benannte Gruppeneinträge sind nicht implementiert. Die Quelle enthält keinen Parser oder Formatierer für ACL-Datensätze, keine ACL-Maske und keine setfacl- oder getfacl-Operation. Diese Konzepte motivieren möglicherweise zur Verwendung eines externen Zugriffskontrollmechanismus, aber dieser Artikel kann keine Befehlssyntax oder ein Befehlsverhalten spezifizieren, das über die Anerkennung der expliziten Grenzen des Rechners hinausgeht.
Halten Sie den Basismodus sichtbar, während Sie diese separate Arbeit ausführen. Geben Sie den gemeldeten Oktalwert ein, überprüfen Sie den Besitzer, die Gruppe und andere Tripel und notieren Sie alle Sonderbits. Verwenden Sie dann eine verlässliche Dateisystemdokumentation und geeignete externe Tools für benannte Einträge. Die vom Rechner generierte chmod-Vorschau erstellt, prüft oder behält keine ACL bei.
Benannte ACL-Einträge erfordern externe Tools, die hier nicht implementiert sind
Die Beziehung zwischen einer chmod-Änderung, Gruppenklassenbits und einer ACL-Maske hängt von einem Verhalten ab, das hier nicht implementiert ist. Der Rechner konvertiert einfach einen Zwölf-Bit-Modus und gibt ein Zuweisungs- oder Oktalargument aus. Es gibt keinen ACL-Status, anhand dessen effektive Rechte berechnet werden können, daher kann nicht vorhergesagt werden, ob ein benannter Eintrag begrenzt wird.
Vermeiden Sie es, eine ACL-Konsequenz allein anhand der Modusausgabe zu beschreiben. Eine Änderung von 0640 zu 0600 entfernt nachweislich die drei Gruppenklassenbits in diesem Modell; Alles, was mit benannten Benutzern, benannten Gruppen oder Masken zu tun hat, erfordert die tatsächlichen ACL- und Plattformregeln. Überprüfen Sie diese anhand der Dateisystemdokumentation, bevor Sie den angezeigten Befehl auf ein ACL-tragendes Objekt anwenden.
ACL-Maskeninteraktion mit chmod erfordert Dateisystemdokumentation
Die Standard-ACL-Vererbung liegt ebenfalls außerhalb der Route. Die Seite verfügt über keine Verzeichnis-ACL-Eingabe, keinen Erstellungsvorgang und kein umask-Feld. Wenn Sie den Zielselektor von Datei auf Verzeichnis umstellen, werden die angehängten einfachen englischen Verben in einen festen Modus versetzt. Es erstellt keine Datei, modelliert keine Vererbung und berechnet auch nicht die Berechtigungen eines zukünftigen Objekts.
Aus dem gleichen Grund kann ein aktueller Verzeichnismodus hier nicht den Modus jedes neuen Kindes vorhersagen. Der Rechner kann erklären, dass das Lesen, Schreiben und Ausführen von Verzeichnissen dem Auflisten, Ändern von Einträgen und dem Erreichen benannter Inhalte entspricht. Es kann diese Basisbits nicht mit Standardeinträgen, Erstellungsanforderungen oder Prozessmasken kombinieren, die es nie erhält.
Die Standard-ACL-Vererbung und die umask-Interaktion liegen außerhalb dieser Route
Erwägen Sie den bereitgestellten Basismodus 0640 für eine Datei, die möglicherweise einen zusätzlichen Reader benötigt. Der Rechner rendert rw-r-----: Besitzer liest und schreibt, Gruppe liest, andere nicht. Das ist die vollständige Aussage, die durch ihre Eingaben unterstützt wird. Es identifiziert weder den Prüfer noch bietet es eine vierte Klasse, in die diese Identität eingeordnet werden kann.
Behalten Sie diesen Basismodus-Datensatz bei, während ACL-Arbeiten an anderer Stelle stattfinden. Wenn der externe Prozess später einen anderen Modus meldet, dekodieren Sie ihn erneut und vergleichen Sie jede Klasse. Fügen Sie keinen ACL-Befehl in das Modusfeld ein und gehen Sie nicht davon aus, dass die Befehlsvorschau benannte Einträge enthält. Es stellt immer nur den aktuell angezeigten numerischen Modus dar.
Funktioniertes Beispiel: Halten Sie den Basismodus lesbar, während ACL-Arbeiten an anderer Stelle stattfinden
Andere ACL-Familien, Remote-Dateisystemregeln und Mount-Unterstützung werden von diesen Quellen nicht eingerichtet. Der Rechner erkennt den Speichertyp, die bereitgestellten Optionen, das Betriebssystem oder die Verfügbarkeit von ACL-Vorgängen nicht. Eine fehlende ACL-Ansicht ist daher eine Implementierungsgrenze und kein Beweis dafür, dass dem zugrunde liegenden Objekt umfassendere Zugriffskontrollen fehlen.
Obligatorische Richtlinien, Fähigkeiten, Eigentum und Prozessidentität sind ebenfalls getrennt. Selbst eine vollständige Kenntnis des Basismodus kann diese Eingaben nicht ersetzen. Melden Sie die Moduskonvertierung als eine Ebene und kennzeichnen Sie jede nicht beobachtete Ebene explizit. Dadurch wird verhindert, dass eine saubere rwx-Anzeige mit einer vollständigen Berechtigungsanalyse verwechselt wird.
Andere ACL-Modelle und Mount-Unterstützung werden nicht abgeleitet
Wenn drei Klassen ausreichen, liefert der Rechner eine präzise, umkehrbare Darstellung dieser Klassen. Wenn dies nicht der Fall ist, halten Sie das Basiskonto lesbar, anstatt eine benannte Ausnahme in der anderen Klasse zu erzwingen. Oktal-, Symbol- und Kontrollkästchenansichten sollten sich auf denselben Eigentümer-, Gruppen-, Sonstiges- und Sonderbitwert einigen.
Die Stoppregel ist einfach: Verwenden Sie diese Route für die Basismodus-Arithmetik und externe, maßgebliche Tools für den ACL-Status. Schließen Sie benannte Einträge, Masken, Vererbung oder Dateisystemunterstützung niemals allein von rwx ab. Eine sorgfältige Prüfung kombiniert diese separaten Beweisquellen, ohne vorzutäuschen, dass der Rechner Zugriffskontrollstrukturen implementiert, die sein Quellcode nicht enthält.