☰

Warum Unix-Kindprozesse [die meisten] Attribute von Elternprozessen erben

tag-icon • tag-icon linux unix permissions process
Warum Unix-Kindprozesse [die meisten] Attribute von Elternprozessen erben

Ich habe gelernt, wie Unix-Prozesse funktionieren, und festgestellt, dassuntergeordnete Prozesseerbt die meisten Attribute (einschließlich Dateideskriptoren) vom übergeordneten Prozess. Ich habe auch gerade erfahren,Ausführungund wie es die Attribute des untergeordneten Prozesses durch völlig neue ersetzt (neuer Speicherplatz usw.), aber die ursprüngliche Prozess-ID beibehält.

Dann weiß ich BescheidSandbox-Umgebungen in Node.js, wobei Ihnen im Wesentlichen eine leere Tafel bereitgestellt wird und Sie dem Kontext des untergeordneten Prozesses Variablen und „Features“ hinzufügen.

Ich frage mich, welche unterschiedlichen Konfigurationen es für die Attribute gibt, die ein Kindprozess erhält, und warum der Kindprozess in Unix standardmäßig alle Attribute des Elternprozesses erbt. Ich frage mich, warum er nicht stattdessen seinen eigenen Speicherplatz usw. hat.

Ich frage mich auch, ob es für diese beiden Fälle (alle übergeordneten Attribute erben oder keines erben) alternative „Attributkonfigurationen für untergeordnete Prozesse“ gibt. Vielleicht möchte es die Hälfte des übergeordneten Adressraums erben oder einen Teil des Adressraums eines Geschwisterprozesses verwenden oder einige Dateideskriptoren des übergeordneten Prozesses sowie einige seiner eigenen verwenden usw. Vielleicht sagen Sie, es kann auf einige Gerätetreiber zugreifen und auf andere nicht usw.

Wäre interessant zu wissen, ob es eine Möglichkeit gibt, solche „Konfigurationsfunktionen“ beim Erstellen eines untergeordneten Prozesses zu übergeben, entweder unter Unix oder unter einem anderen Betriebssystem. Beispiel: „Untergeordneten Prozess erstellen, dabei die Hälfte des Adressraums des übergeordneten Prozesses, 1/4 des Adressraums des Geschwisterprozesses 2, 1/8 des Adressraums des Geschwisterprozesses 1 verwenden und das verbleibende 1/8 meinen eigenen lokalen Adressraum verwenden. Außerdem Zugriff auf die Gerätetreiber a, b und c gewähren und ansonsten keinen Netzwerkzugriff zulassen.“ Etwas Beliebiges, bei dem es im Grunde darum geht, den „Funktionsumfang“ des untergeordneten Prozesses bis ins kleinste Detail zu konfigurieren.

Ich frage mich, ob so etwas unter Unix oder anderen Betriebssystemen vorkommt und wenn nicht, warum nicht. Ich verstehe nicht, warum die Entscheidung getroffen wurde, nur diese beiden Fälle von Genehmigungs-/Regulierungsprozessen zu haben.

Es scheint, dass sich dies irgendwie überschneidet mit demSchutzringKonzept. Sie verhindern, dass Userland-Prozesse (untergeordnete Prozesse) auf bestimmte Funktionen zugreifen. Ich frage mich, warum es nicht auf höherer Ebene konfigurierbarer ist.

Antwort1

Sie vermischen hier Äpfel, Orangen und Grapefruits.

  • "node.js" ist beispielsweise das JavaScriptHochsprache,was nichts mit Betriebssystemprozessen zu tun hat. (JavaScript wird vollständig in einem Prozess oder Thread ausgeführt, der vom Host bereitgestellt wird.)

  • „Ringe“ oder allgemeiner „CPU-Berechtigungsstufen“ sindphysikalische Eigenschaften des Mikroprozessorchips,wird verwendet, um zu bestimmen, welche CPU-Anweisungen ein Programm ausgeben darf und auf welche Ressourcen es zugreifen kann.

  • Das Unix/LinuxSoftwareArchitektur, die für diese Betriebssysteme recht spezifisch ist, ist eng verbunden mit dem Konzept von„Gabelung“,das wie folgt aussieht:

    if (pid = fork()) {
    ... you are the parent, and 'pid' is the child's process-id ...
} else {
    ... 'pid' is zero, so you are the child ...
}

Damit diese nette Idee funktioniert, muss der Großteil des Kontexts des übergeordneten Elements in das untergeordnete Element kopiert werden.

Der exec()Systemaufruf kann (von einem untergeordneten Element) verwendet werden, um seinen gesamten Kontext durch den eines neuen Prozesses zu ersetzen, wodurch die gesamte „Vererbung“ vom übergeordneten Element getrennt wird.

verwandte Informationen