Was hat das Sticky Bit ursprünglich getan, wenn es auf Dateien angewendet wurde?

An verschiedenen Stellen kann man das "Sticky Bit" sehen, das heutzutage als völlige Fehlbezeichnung beschuldigt wird, da seine Funktionalität heutzutage darin besteht, die Schreibberechtigungen für Verzeichnisse zu beeinflussen und als eingeschränktes Löschflag zu fungieren .

In einer AskUbuntu-Antwort schrieb der Antwortende, dass "ein Sticky-Bit normalerweise für Verzeichnisse gilt" . Ich bemerkte, dass moderne Systeme in der Praxis in der Tat scheinen, es niemals auf Dateien anzuwenden, aber dass es vor langer Zeit üblich war, dass es auf (ausführbare Programmabbilder) Dateien und nicht auf Verzeichnisse angewendet wurde. (Wenn es um den Mangel an moderner Dateiverwendung geht , gibt es eine verwandte Frage unter Ist das Sticky-Bit in aktuellen Dateisystemen nicht verwendet .)

Dies warf die Frage auf:

Was hat ein Sticky-Bit, das auf eine ausführbare Datei angewendet wurde, bewirkt? War es damals wie setuid?

Beachten Sie die Vergangenheitsform. Dies ist nicht Wie funktioniert das klebrige Stück? jetzt. So hat es damals funktioniert.

Nein, das Sticky-Bit entsprach nicht den Flags set-UID oder set-GID. Es wurden keine Änderungen an den Anmeldeinformationen vorgenommen.

Was das Sticky-Bit tat, war, den Programmtext "sticky" zu machen. Es war ursprünglich keine falsche Bezeichnung.

Hintergrund: Programmabschnitte und geteilter Text

Im Wesentlichen, ohne zu tief in die Details der ausführbaren Dateiformate (die Bücher füllen können und müssen) zu gehen: Die Teile der Programm-Image-Dateien, die direkt in den Speicher geladen werden, um Programme auszuführen, umfassen Maschinencode, Konstanten und den Start Werte von (nicht mit Null initialisierten) Variablen und (in der einen oder anderen Form) Leerzeichen für mit Null initialisierte und nicht initialisierte Variablen.

Diese sind in Sammlungen zusammengefasst, die als "Abschnitte" bezeichnet werden, und sie haben herkömmliche Namen. Der Maschinencode und (manchmal) die Konstanten bilden den sogenannten "Text" -Abschnitt eines Programmabbilds. Die nicht mit Null initialisierten Variablen sind in ähnlicher Weise der Abschnitt "Daten"; und die mit Null initialisierten und nicht initialisierten Variablen sind "bss" (ein Name, der selbst eine ganze folkloristische Geschichte hinter sich hat).

Wenn in einen Prozess eine vom Programm ausführbare Bilddatei geladen ist, werden die verschiedenen Teile - Text, Daten und BSS - anhand des Inhalts der Bilddatei initialisiert.

Das Besondere am Abschnitt "Text" ist, dass der Maschinencode (und die Konstanten) fast immer nicht beschrieben werden. Es besteht die Möglichkeit, dass die Images des virtuellen Speichers aller ausgeführten Prozesse, in die diese ausführbare Image-Datei geladen wurde, gemeinsam genutzt werden. Das genaue Szenario, in dem Programmtext gemeinsam genutzt werden kann, ist für diese Antwort nicht relevant und umfasst Dinge wie die Behebung der IDempotenz des Loaders und die Identität des Adressraum-Layouts. Menschen können und haben auch Bücher zu diesem Thema geschrieben. ☺

Geteilter Text ist eine Optimierung, die vom Kernel verwendet wird. Es entfällt die Notwendigkeit, dass jede Instanz eines einzelnen laufenden Programm-Images ein eigenes individuelles Speicher-Image hat, wodurch wertvoller physischer Speicher mit mehreren Kopien des exakt gleichen Maschinencodes (und der Konstanten) belegt wird.

klebriger Text

Aber man kann noch besser als geteilten Text. Wenn immer mindestens ein Prozess ausgeführt wird, der ein bestimmtes Image eines gemeinsam genutzten Textprogramms verwendet, kann der Kernel den virtuellen Speicherbereich des neuen Prozesses beim Ausführen einer neuen Instanz des Programms einfach an das vorhandene Segment für gemeinsam genutzten Text anhängen. Es gibt fast immer eine Instanz von (sagen wir) /bin/loginoder /bin/shläuft irgendwo auf einem mittelgroßen System, so dass neue Instanzen des Login - Programm oder der Standard - Shell kann einfach auf die geladenen Kopien ihrer Textsegmente anhängen , die der Kernel bereits in den Speicher geladen wurde.

Sticky-Text erweitert diese Idee, um Bilder zu programmieren, die derzeit von keinem Prozess ausgeführt werden . Wenn eine ausführbare Image-Datei als klebriger Text markiert ist, behält der Kernel das Textsegment nach dem letzten Vorgang bei, bei dem er beendet wurde. in der Hoffnung, dass bald eine weitere Instanz des Programms ausgeführt wird und sich einfach wieder an das Segment anhängen lässt.

In früheren Unices wurden geladene klebrige Textsegmente ausgelagert, um den Speicher auszutauschen, wenn kein Prozess mit ihnen verbunden war. (Spätere Unices haben Swap dafür nicht mehr verwendet.) Möglicherweise haben Sie auch vom Namen des gespeicherten Texts gehört .

Das Setzen des Sticky-Text-Bits in einem Programm-Image muss natürlich mit Sorgfalt erfolgen. Welche Programme davon profitieren, hängt davon ab, wofür die Maschine im Allgemeinen verwendet wird. Derzeit belegen nicht angehängte Textsegmente Kernelressourcen, sodass die Anzahl der Elemente in einem System praktisch begrenzt ist. Es handelt sich also im Allgemeinen um eine Operation, die Superuser-Berechtigungen erfordert.

Enttäuschung

Es gibt eine ganze Reihe von Annahmen, die der Funktion von klebrigem Text zugrunde liegen und die einfach nicht mehr zutreffen. Das Lesen eines vorgefertigten Segments aus dem Auslagerungsspeicher ist nicht unbedingt schneller als das einfache Einlagern aus der eigentlichen ausführbaren Image-Datei. Die Dateisystemformate wurden für zufällige (im Gegensatz zu sequentiellen) Lesemuster verbessert. Das Aufkommen von Demand-Paging selbst ändert Dinge, wie beispielsweise einheitliche Caches, nicht-idempotente externe Korrekturen, die sich aus Unterschieden bei der Suche in gemeinsam genutzten Bibliotheken ergeben, und die Randomisierung des Adressraum-Layouts.

Die Zeiten der klebrigen Textbits für ausführbare Programmbilder sind lange vorbei. Ein explizites Sticky-Text-Marker-Flag für ausführbare Programmbilder wurde beispielsweise von den Autoren von 4.3BSD Mitte der 1980er Jahre als veraltet angesehen.

Weitere Lektüre

• Maurice J. Bach (1986). Das Design des UNIX-Betriebssystems . Prentice-Hall. ISBN 9780132017992.