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

Question

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

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

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

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

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

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

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

Answer 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() может использоваться (дочерним) для замены всего его контекста контекстом какого-либо нового процесса, в результате чего все "наследование" от родителя прерывается.