Базируйтесь и войдите в систему сеансы
С самого начала OS X был разработан, чтобы быть безопасной операционной системой. Одним аспектом этой безопасности является контроль, осуществленный над межпроцессным взаимодействием. Процессы свободно собраны в группы и связаны или с корневым сеансом или с сеансом входа в систему. launchd демон присваивает каждый новый процесс надлежащему сеансу на основе факторов такой как, кто создал процесс и когда. launchd демон включает функциональность, ранее созданную в mach_init демон, и когда действие в этой способности также известно как сервер начальной загрузки.
Большинство процессов корневого уровня помещается в корневой сеанс. Корневой сеанс является первым сеансом, который будет создаваться и последнее, которое будет уничтожено. Только один корневой сеанс когда-либо существует в системе, и это - где живут большинство процессов времени начальной загрузки и демонов. Процессы в корневом сеансе независимы от пользователя и продают базовые услуги любому в системе. Например, mDNSResponder обработайте выполнения в корневом сеансе.
Процессы, запущенные пользователем или для преимущества пользователя, живут в сеансе входа в систему. Каждый сеанс входа в систему связан с аутентифицируемым пользователем. Система может иметь многократные сеансы входа в систему, активные в любой момент времени, но каждый - что-то вроде острова связанному пользователю. Консольные сеансы входа в систему включают процессы, такие как Средство поиска и Прикрепление; однако, соединения удаленного входа в систему содержат только процессы уровня оболочки. Большая часть коммуникации между различными сеансами входа в систему ограничивается сервером начальной загрузки. Коммуникация все еще возможна, но обычно требует создания явного, и доверяла, соединение.
Обеспечение пространства пользователя
Путем организации процессов в корень и сеансы входа в систему, launchd процесс в состоянии создать более защищенную среду для пользователей. Запросы на порты Маха проходят через launchd процесс, направляющий запросы к надлежащей цели. Сеанс входа в систему действует как ряд стен вокруг процессов пользователя, ограничивая запросы порта теми в текущем сеансе входа в систему или корневом сеансе. Выполнение так предотвращает случайные или намеренные попытки процессов в различном сеансе для получения доступа к портам в текущем сеансе входа в систему. В некотором смысле сеансы входа в систему являются легким брандмауэром вокруг процессов, которые они представляют.
Таким образом сеансы входа в систему дают пользователям обеспечение, что процессы, запущенные другими пользователями, не вмешиваются в их собственные процессы. Например, злонамеренный пользователь мог бы записать программу, симулирующую быть известной пользовательской службой и использовать ту программу для сбора информации от других пользователей. Однако, если у злонамеренного пользователя нет административного доступа к машине, выполнений программы в сеансе входа в систему злонамеренного пользователя. Поскольку другие пользователи не видят программу, они защищены от ее эффектов.
Передача через сеансы входа в систему
Во время начальной загрузки ядро запускается launchd процесс, который ответственен за обрабатывание запросов поиска для портов Маха (среди прочего). Как часть каждого запроса, launchd также гарантирует, чтобы процессы не пытались пересечь границы сеанса входа в систему незаконно. Это не означает, что полностью запрещается пересечение границ сеанса. Существуют ситуации, где это является надлежащим и даже необходимым. Например, приложения могут использовать сокеты BSD, совместно используемые файлы, общую память или распределенные уведомления для передачи с процессами в других сеансах; однако, выполнение так требует сотрудничества между обоими сеансами и включает определенный уровень доверия.
Концептуально, можно думать о корневом сеансе как о родительском сеансе для всех следующих сеансов входа в систему. Однако родительско-дочерняя аналогия заканчивается там. Процессы в корневом сеансе не имеют никакого свойственного знания процессов ни в одном из активных сеансов входа в систему. С другой стороны процессы в сеансах входа в систему действительно имеют знание процессов в корневом сеансе и могут получить доступ к ним по мере необходимости для надлежащих служб. Пользовательские процессы в одном сеансе входа в систему не имеют никакого свойственного доступа к процессам в других сеансах входа в систему, все же. Рисунок 1 иллюстрирует это отношение.
Процессы в корневом сеансе не являются абсолютно слепыми к процессам в сеансах входа в систему. Когда пользовательский процесс запрашивает службу от демона, работающего в корневом сеансе, процесс обычно обеспечивает адрес порта, по которому можно возвратить результаты. Поскольку это имеет явный порт Маха, чтобы говорить, демон может теперь отправить результаты запроса непосредственно назад к пользовательскому процессу. Рисунок 2 иллюстрирует это поведение.
Продолжительность жизни сеанса
Как Вы могли бы ожидать, корневой сеанс является первым, чтобы быть созданным в системе. Когда система закрывается, это является также последним, чтобы быть уничтоженным. Корневой сеанс является логическим местом, в котором можно выполнить демонов и системные службы, применяющиеся ко всем пользователям. Однако запись демону для выполнения в корневом сеансе устраняет использование многих высокоуровневых системных платформ, требующих присутствия сервера окна. (Для списка платформ можно использовать, видеть Платформы, Доступные в Корневом Сеансе.)
Когда пользователь входит в систему, или через окно входа в систему или ssh, система создает новый сеанс входа в систему. Сеанс входа в систему остается существующим, пока не завершаются все процессы, принадлежащие ему. Когда пользователь выходит из системы, система пытается завершить процессы в сеансе входа в систему того пользователя. Когда последний процесс в сеансе входа в систему умирает, система закрывает сеанс входа в систему и предъявляет претензии в отношении его памяти.
Приложения могут задержать пользовательский выход из системы по различным причинам, описанным в Руководстве по программированию Демонов и Служб. Службы в расчете на пользователя закрываются автоматически и не даны шанс прервать процедуру выхода из системы.
Идентификация сеансов входа в систему
Каждый раз, когда пользователь аутентифицируется с системой, Уровень безопасности системы создает уникальный идентификатор для идентификации сеанса входа в систему пользователя. Этот ID является сеансом безопасности ID, часто именуемый просто как сеанс ID. Приложения могут использовать сеанс ID для различения среди ресурсов, выделенных в различных сеансах входа в систему.
Сеанс IDs не является персистентным между пользовательским именем для входа в систему. Каждый сеанс ID допустим только на время текущего сеанса входа в систему, и это допустимо для всех процессов в том сеансе входа в систему. Если пользователь выходит из системы, и журналы въезжают задним ходом, различный сеанс, ID присваивается новому сеансу входа в систему.
Необходимо использовать сеанс IDs для предотвращения конфликтов пространства имен с объектами в других сеансах входа в систему. Если бы приложение использовало общее название для специфичной для сеанса области общей памяти, то то же приложение в другом сеансе, вероятно, встретилось бы с ошибкой при попытке создать ту область памяти с помощью того же имени. Включая сеанс ID на имя области памяти может предотвратить эти виды ошибок.
Для получения информации о том, как получить сеанс IDs, посмотрите Получающую информацию Сеанса Входа в систему.
Как разработчики влияния сеансов входа в систему
Если Вы пишете приложения для конечных пользователей, существование сеансов входа в систему требует более мысли в Вашем проекте. Необходимо помнить, что многократные экземпляры приложения могут работать одновременно и писать код для обработки потенциальных конфликтов ресурса. Если необходимо связаться с процессами в других сеансах входа в систему, необходимо использовать сокеты BSD, распределенные уведомления или некоторую другую форму доверительного соединения.
Если Вы пишете только код ядра, корень и сеансы входа в систему в основном не важны. Однако разработчики драйвера часто должны писать программы, работающие или в ядре или в корневом сеансе и связывающиеся с программами в одном или более сеансах входа в систему. Например, разработчик драйвера мог бы хотеть сконфигурировать аудиодрайвер на основе предпочтений активного пользователя. В этом случае было бы необходимо записать программу агента, чтобы работать в каждом сеансе входа в систему и передать изменения пользовательского уровня в драйвере.
Платформы, доступные в корневом сеансе
Много системных платформ зависят от сервера окна для части их реализаций. Они или используют сервер окна для рисования графики для отслеживания уведомлений, или для координирования с системой другими способами. Для большинства приложений это не проблема вообще и фактически необходимо для реализации некоторых способов поведения. Однако, если Вы пишете демону или другому типу программы для выполнения в корневом сеансе, нет никакого серверного процесса окна, с которым можно связаться. В результате много высокоуровневых платформ не могут использоваться вообще.