☰

Почему дочерние процессы Unix наследуют [большинство] атрибутов родительского процесса

tag-icon • tag-icon linux unix permissions process
Почему дочерние процессы Unix наследуют [большинство] атрибутов родительского процесса

Изучая, как работают процессы Unix, я заметил, чтодочерние процессынаследуют большинство атрибутов (включая дескрипторы файлов) от родительского процесса. Я также только что узнал оисполнительныйи как он заменяет атрибуты дочернего процесса на совершенно новые (новое пространство памяти и т. д.), но сохраняет исходный идентификатор процесса.

Тогда я знаю оПесочницы в Node.js, в котором он предоставляет вам по сути чистый лист, а вы добавляете переменные и «функции» в контекст дочернего процесса.

Мне интересно, какие существуют различные типы конфигураций для атрибутов, которые получает дочерний процесс, и почему дочерний процесс в Unix "по умолчанию" наследует все родительские атрибуты. Интересно, почему бы ему вместо этого не иметь свое собственное пространство памяти и все такое.

Также интересно, есть ли альтернативные "конфигурации атрибутов дочернего процесса" для этих 2 случаев (наследовать все родительские атрибуты или не наследовать ни одного). Может быть, он захочет унаследовать половину родительского адресного пространства или использовать часть адресного пространства из родственного процесса, или использовать несколько файловых дескрипторов из родительского процесса, а также некоторые из своих собственных и т. д. Может быть, вы скажете, что он может получить доступ к нескольким драйверам устройств, а к другим нет и т. д.

Было бы интересно узнать, есть ли способ передать такие "конфигурационные возможности" при создании дочернего процесса, как в Unix, так и в любой другой операционной системе. Например, "создать дочерний процесс, используя половину родительского адресного пространства, 1/4 адресного пространства сестринского процесса 2, 1/8 адресного пространства сестринского процесса 1, а оставшуюся 1/8 часть использовать мое собственное локальное адресное пространство. Также предоставить доступ к драйверам устройств a, b и c, а в противном случае не разрешать сетевой доступ". Что-то произвольное, где это в основном настройка "набора возможностей" дочернего процесса на тонком уровне детализации.

Интересно, происходит ли что-то подобное в Unix или других операционных системах, и если нет, то почему. Я не понимаю, почему было принято решение иметь только эти 2 случая разрешающих/регулирующих процессов.

Кажется, это как-то пересекается сзащитное кольцоКонцепция. Вы запрещаете пользовательским процессам (дочерним процессам) получать доступ к определенным функциям. Интересно, почему это не более настраиваемо, чем это, на высоком уровне.

решение1

Здесь вы смешиваете яблоки, апельсины и грейпфруты.

  • Например, "node.js" — это JavaScriptязык высокого уровня,который не имеет ничего общего с процессами операционной системы. (Весь JavaScript выполняется в рамках процесса или потока, предоставленного его хостом.)

  • «Кольца» или, в более общем смысле, «уровни привилегий ЦП» — этофизические характеристики микропроцессорного чипа,используется для определения того, какие инструкции процессора разрешено выдавать программе и к каким ресурсам она может получить доступ.

  • Unix/Linuxпрограммное обеспечениеархитектура, которая весьма специфична для этих операционных систем, тесно связана с понятием"разветвление,"который выглядит так:

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

Чтобы эта изящная идея сработала, большую часть контекста родителя необходимо скопировать в дочерний элемент.

Системный exec()вызов может быть использован (дочерним процессом) для замены всего своего контекста контекстом какого-либо нового процесса, в результате чего все «наследование» от родителя будет разорвано.

Связанный контент