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


65

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.


3
Ich möchte darauf hinweisen, dass "ich in der Tat festgestellt habe, dass moderne Systeme sie in der Praxis niemals auf Dateien anwenden", was nur für einige Systeme zutrifft. Wikipedia-Seite zu Haftnotizen: "Derzeit ist dieses Verhalten nur in HP-UX und UnixWare möglich." Es enthält eine Tabelle mit verschiedenen Implementierungen: Der allgemeine Thread besteht darin, dass Betriebssysteme ihn ignorieren oder ihn behandeln, um zu ermitteln, wie Speicher / Swap / etc. sollte gehandhabt werden. Die Details, wie das verwandt wurde, variieren zwischen Betriebssystemen. ZB verwendeten keine Linux-Systeme jemals das Sticky-Bit wie die Antwort von JdeBP.
TOOGAM

Antworten:


91

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.

1
Sehr nette Antwort! Heute habe ich etwas gelernt. :)
Andreas Wiese

Ich auch :) Das hört sich sehr nach dem an, was ich TSRin den DOS-Tagen gewusst habe - "kündigen und wohnhaft bleiben". Dies galt jedoch in der Regel für Dinge wie Gerätetreiber, die andere Prozesse, die später ausgeführt werden, aufrufen müssen, und war wahrscheinlich veraltet, als die Welt auf Betriebssysteme mit mehreren Threads und Prozessen umstellte.
Steve

1
Das ist eine großartige Antwort. Wo kann ich über die Entstehung von lesen bss?
Katze

1
TSRs sind nicht wirklich analog. Analoge zur IBM + Microsoft-Welt finden Sie in DOS + Windows 3.x im Standardmodus und in 16-Bit-OS / 2-Version 1.x. Die CODESegmente (und schreibgeschützten OS / 2- DATASegmente) von EXE-Dateien und DLL-Dateien werden (normalerweise) von allen ausgeführten Programmen gemeinsam genutzt. Es gibt kein wirkliches Äquivalent zu "Klebrigkeit", zum Teil, weil 32-Bit-OS / 2-Version 2.x und 386 Enhanced Mode den Segment-Austausch durch nachfrageseitig ausgelagerten virtuellen Speicher ersetzten, so wie es die Unix-Welt vor einigen Jahren in beiden Bereichen der Fall war Notwendigkeit für die Segmentierung Klebrigkeit in ähnlicher Weise.
JdeBP

3
@JdeBP: Die Frage "War das klebrige Stück wie setuid?" ist ziemlich breit und ungenau. Ich würde argumentieren, dass die Antwort "Nun, etwas, es ist kompliziert" ist, weil die niederwertigen neun Bits ähnlich waren und sind: Sie beeinflussen, ob bestimmte Benutzer bestimmte Operationen an einer Datei ausführen dürfen. Und das Set-UID, Set-GID und Haftbits waren ähnlich, dass sie nicht bezögen , ob eine Operation erlaubt war, sondern moderierten stattdessen einen Aspekt , wie es (insbesondere der Ausführungsvorgang) durchgeführt wurde.
G-Man
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.