Deutsch

Entwicklertools · Chmod-Rechner

Die zwei Leben des Sticky-Bits: vom Swap-residenten Text zu /tmp

· Hintergrund

chmod Unix Zugriffskontrolle

Sticky-Rendering wird als eindeutiges Unix-Berechtigungsbitdiagramm angezeigt
Original-ToolAcre-Vektorillustration

Das t im /tmp's-Modus bedeutete unter Unix der 1970er Jahre etwas völlig anderes. Dieser Beitrag folgt dem Sticky-Teil von einem Leistungshinweis bis zu einer Löschregel und erklärt, was es heute tut.

drwxrwxrwt auf /tmp – der letzte Buchstabe ist nicht r, w oder x, und die übliche Ein-Wort-Erklärung erklärt nichts

Die Zeichenfolge drwxrwxrwt zeigt, warum gewöhnliche rwx-Arithmetik nicht die ganze Geschichte ist. Sticky ist das Bit 1000, das an der endgültigen Ausführungsposition gerendert wird. Wenn other-execute vorhanden ist, ist das Zeichen der Kleinbuchstabe t; ohne es erscheint der Großbuchstabe T. Die Eingabe von 1777 erzeugt daher rwxrwxrwt, während die vierstellige Zusammenfassung die führende Sonderbitziffer beibehält.

Diese Anzeige konvertiert einen bereitgestellten Modus; Es wird kein Verzeichnis überprüft. Die Seite teilt einen Wert in Besitzer-, Gruppen-, andere und spezielle Bits auf und erstellt dann jede Ansicht aus diesen Teilen neu. Ihre Vereinbarung überprüft die Arithmetik, nicht den Besitz, ACLs oder Dateisystemrichtlinien. Der generierte chmod-Befehl bleibt Klartext, bis ihn jemand anderswo ausführt.

Die ursprüngliche Bedeutung – das Textsegment eines Programms nach dem Beenden im Austausch halten, damit die nächste Ausführung auf langsamen Festplatten schneller startet

Die Erklärung der regulären Datei besagt, dass Sticky einmal angefordert hat, dass der Programmtext im Swap verbleibt. Das ist die vollständige historische Behauptung, die durch diese Quellen gestützt wird. Sie nennen kein primäres Unix-Handbuch, kein Datum, kein benanntes System oder kein Maß für die Akzeptanz. Eine sorgfältige Betrachtung kann die frühere Dateibedeutung mit dem aktuellen Verzeichnisverhalten vergleichen, ohne einen umfassenderen Betriebssystemverlauf zu erfinden.

Der Rechner ermittelt, wie das Bit dargestellt wird. Sticky belegt das Oktal 1000 und teilt sich in symbolischer Notation die Other-Execute-Position. Somit endet 1777 mit t, weil „execute“ festgelegt ist, während 1644 mit „T“ endet, weil es nicht vorhanden ist. Die Bitmasken-, Parser-, Renderer- und Round-Trip-Tests unterstützen diese Fakten, keine Chronologie des Kernel-Verhaltens.

Die Quelle beschreibt einen früheren Dateihinweis, liefert jedoch kein primäres Geschichtszitat

Für reguläre Dateien beschreibt das Tool Sticky als einen historischen Swap-Hinweis, den moderne Kernel ignorieren. Der Wortlaut sollte nicht zu einem universellen Anspruch für jeden Kernel oder jedes Dateisystem werden. Dieses Repository bietet eine Rechnererklärung, keine Plattformumfrage. Sein vertretbarer Punkt ist enger gefasst: Sticky verändert nicht die angezeigten Lese-, Schreib- oder Ausführungsberechtigungen für eine reguläre Datei.

Die Darstellung bleibt genau, auch wenn keine Vollstreckung beansprucht wird. Wenn other-execute gesetzt ist, ist das letzte Zeichen t; Ohne es ist dieses Zeichen T. Der Parser stellt beide Formen im Sticky-Bit wieder her und die Tests decken 1777, 1644 und jeden Modus bis 7777 ab. Keiner startet Programme, mountet Dateisysteme oder fragt einen Kernel nach tatsächlichem Verhalten ab.

Die Erklärung zu regulären Dateien besagt, dass moderne Kernel Sticky ignorieren; Es wird kein allgemeingültiger Anspruch erhoben

Verzeichnisverhalten ist die moderne Verwendung, die die Implementierung direkt erklärt. Bei einem freigegebenen Verzeichnis fügt Sticky eine Lösch- und Umbenennungsbeschränkung hinzu: Personen können Einträge erstellen, das Entfernen ist jedoch auf den Besitzer oder Root eines Eintrags beschränkt. Die Voreinstellungen erfassen 1777 als Muster /tmp, während die Erklärung warnt, wenn ein Verzeichnis von jedem ohne Sticky beschreibbar ist.

Die Anzeige legt diesen Unterschied offen, ohne den Anspruch zu erheben, sie zu prüfen. /tmp. Die Modi 777 und 1777 teilen sich die gewöhnlichen Berechtigungen rwxrwxrwx. Durch das Hinzufügen von 1000 wird das endgültige symbolische x in t geändert und +t an generierte Zuweisungen angehängt. Eigentümer-, Gruppen- und andere Zuschüsse bleiben ansonsten unverändert; Echter Besitz, ACLs und Dateisystemregeln bleiben außerhalb der Berechnung.

Verzeichnis-Sticky-Verhalten ist die derzeit implementierte Erklärung

Der Verzeichnissatz enthält eine eingeschränkte Regel: Wenn Sticky festgelegt ist, darf nur der Eigentümer oder Root einer Datei diese löschen oder umbenennen. Das Tool löst keine Identitäten auf, prüft den Verzeichnisbesitz nicht und versucht auch nicht, einen Vorgang auszuführen. Ein angezeigtes 1777 bestätigt universelle RWX-Bits plus Sticky, kann aber nicht identifizieren, wem ein Eintrag gehört, der in einen echten Streit verwickelt ist.

Zusätzliche Richtlinien müssen separat untersucht werden. Der Rechner liest keine ACLs, Funktionen, Mount-Optionen, obligatorischen Kontrollen oder Dateisystemstatus. Der Wechsel zwischen Datei und Verzeichnis ändert die Erklärung, nicht den Modus. Wenn eine Umbenennung erfolgreich ist oder unerwartet fehlschlägt, kann die Seite nicht erklären, warum; Es isoliert lediglich die herkömmlichen Bits für eine systemspezifische Untersuchung.

Das Tool beschreibt Eigentümer- oder Root-Löschbeschränkungen, ohne Richtlinienerweiterungen zu prüfen

Vergleichen Sie 1777 und 777 als Verzeichnismodi. Der Modus 777 rendert drwxrwxrwx und ermöglicht jeder Klasse das Auflisten, Erstellen, Eingeben, Umbenennen und Löschen. Das Tool warnt davor, dass Benutzer möglicherweise Einträge löschen, die ihnen nicht gehören. Das Aktivieren von Sticky erzeugt drwxrwxrwt: Die rwx-Zuteilungen bleiben unverändert, während die Löschbeschränkung des Besitzers oder Roots in die Erklärung eingeht.

Generierte Zuweisungen weisen den gleichen Unterschied von einem Bit auf. Modus 777 wird zu u=rwx,g=rwx,o=rwx, während 1777 +t hinzufügt; Die Oktalvorschau behält auch die führende Ziffer. Keine Vorschau öffnet den Pfad oder führt chmod aus. Der Vergleich beweist, dass sich nur 1000 geändert hat, und erklärt seine t-Form, Eigentum und Durchsetzung erfordern jedoch weiterhin eine externe Überprüfung.

Arbeitsbeispiel: Vergleichen Sie die Erklärungen zu 1777 und 777 im Rechner

Der Setgid-Verlauf wird von diesen Materialien nicht unterstützt. Das Repository kann setgid als 2000 kodieren, s oder S in der Gruppenausführungsposition rendern und die Vererbung von Verzeichnisgruppen erklären. Diese Implementierungsdetails dokumentieren nicht die Ursprünge von setgid und stellen keinen Zusammenhang zwischen seiner Entwicklung und Sticky her. Die Arithmetik für ein bestimmtes Bit ist kein historischer Beweis für ein anderes.

Die Richtlinie für geschützte Verzeichnisse liegt auch außerhalb des Quellsatzes. Die Seite liest keine fs.protected-Einstellung, Systemkonfiguration, ACL, Besitzdatensatz oder versuchten Vorgang. Es kann bestätigen, dass ein bereitgestellter Modus Sticky enthält, und seine Basiszuteilungen anzeigen, es kann jedoch nicht bestätigen, dass Sticky die einzige Einschränkung der Maschine ist. Eine umfassendere Diagnose erfordert Beweise aus diesem Umfeld.

Setgid-Verlauf und Richtlinie für geschützte Verzeichnisse bleiben außerhalb des Quellsatzes

Die praktische Unterscheidung passt in ein Zeichen. Bei Verzeichnissen zeichnet t Sticky mit other-execute auf, während T Sticky ohne dieses Ausführungsbit aufzeichnet. Der Rechner behält beide Formen bei und sorgt dafür, dass 1000 in seiner Zusammenfassung sichtbar bleibt. Die Quelle erwähnt auch einen früheren Hinweis aus der regulären Akte, liefert aber zu wenig primäre Beweise, um eine universelle historische Chronologie zu stützen.

Verwenden Sie die Seite, um die Vertretung zu klären, bevor Sie über Richtlinien diskutieren. Geben Sie einen Modus ein, wählen Sie eine Datei oder ein Verzeichnis und vergleichen Sie Oktal-, Symbol-, Matrix-, Zusammenfassungs- und Zuweisungswerte. Die Vereinbarung bestätigt eine konsistente Zwölf-Bit-Konvertierung. Halten Sie hier an, es sei denn, das Zielsystem liefert weitere Beweise: Das Tool identifiziert keine Benutzer, liest keinen Pfad, führt keinen Befehl aus und prüft keine Richtlinienerweiterungen.