Processes in the root session are not completely blind to processes in login sessions. Figure 1 Root and login session relationships User processes in one login session do not have any inherent access to processes in other login sessions, though. Conversely, processes in login sessions do have knowledge of processes in the root session and can access them as needed for appropriate services. Processes in the root session have no inherent knowledge of processes in any of the active login sessions. However, the parent-child analogy ends there. For example, applications can use BSD sockets, shared files, shared memory, or distributed notifications to communicate with processes in other sessions however, doing so requires cooperation between both sessions and involves a certain level of trust.Ĭonceptually, you can think of the root session as a parent session for all of the login sessions that follow. There are situations where it is appropriate and even necessary. This is not to say that crossing session bounds is completely forbidden. As part of each request, launchd also ensures that processes do not attempt to cross login session bounds illegally. Communicating Across Login SessionsĪt boot time, the kernel launches the launchd process, which is responsible for handling lookup requests for Mach ports (among other things). Because other users cannot see the program, they are protected from its effects.

However, unless the malicious user has administrative access to the machine, the program runs in the login session of the malicious user. For example, a malicious user might write a program that pretends to be a known user service and use that program to gather information from other users. Thus, login sessions give users an assurance that processes launched by other users do not interfere with their own processes. In a sense, login sessions are a lightweight firewall around the processes they represent.

Doing so prevents accidental or intentional attempts by processes in a different session to obtain access to the ports in the current login session. The login session acts like a set of walls around a user’s processes, limiting port requests to those in the current login session or root session. Requests for Mach ports go through the launchd process, which routes the requests to the appropriate target. These sections also assume some knowledge of the Mach kernel environment, which is described in Kernel Programming in Darwin Documentation.īy organizing processes into root and login sessions, the launchd process is able to create a more trustworthy environment for users. Important: The content of this article is intended primarily for developers writing daemons and other low-level processes other developers may find the information interesting but should not need it in the general course of development. Communication is still possible but generally requires creating an explicit, and trusted, connection. Most of the communication between different login sessions is restricted by the bootstrap server. Console login sessions include processes such as the Finder and Dock however, remote login connections contain only shell-level processes. The system may have multiple login sessions active at any given time, but each one is something of an island to the associated user. Each login session is associated with an authenticated user. Processes launched by a user or for a user’s benefit live in a login session. For example, the mDNSResponder process runs in the root session. Processes in the root session are user-independent and vend basic services to anyone on the system. Only one root session ever exists on the system, and it is where most boot-time processes and daemons live. The root session is the first session to be created and the last to be destroyed. Most root-level processes are placed in the root session. The launchd daemon incorporates the functionality previously built into the mach_init daemon, and when acting in this capacity is also known as the bootstrap server. The launchd daemon assigns each new process to an appropriate session based on factors such as who created the process and when. Processes are loosely gathered into groups and associated with either the root session or a login session. One aspect of this security is the control exercised over inter-process communication. From early on, OS X was designed to be a secure operating system.

Os xlog into user session