{
	"id": "a0c89fcd-2d7e-4b4b-8ade-e80d19768f0e",
	"created_at": "2026-04-06T00:12:02.442762Z",
	"updated_at": "2026-04-10T13:12:38.26894Z",
	"deleted_at": null,
	"sha1_hash": "e41a337f57721007e82ddba1b4d11b0dd45859e5",
	"title": "Designing Daemons and Services",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 163411,
	"plain_text": "Designing Daemons and Services\r\nPublished: 2016-09-13 · Archived: 2026-04-05 19:23:34 UTC\r\nTwo of the most important design decisions to consider when creating a background process are how it will be run\r\nand how other processes will communicate with it. These two considerations interact with each other: different\r\ntypes of background processes have different forms of communication available to them.\r\nTypes of Background Processes\r\nThere are four types of background processes in OS X. The differences are summarized in Table 1-1 and described\r\nin detail in the following subsections. To select the appropriate type of background process, consider the\r\nfollowing:\r\nWhether it does something for the currently logged in user or for all users.\r\nWhether it will be used by single application or by multiple applications.\r\nWhether it ever needs to display a user interface or launch a GUI application.\r\nTable 1-1  Types of Background Process\r\nType\r\nManaged by\r\nlaunchd?\r\nRun in which\r\ncontext?\r\nCan present UI?\r\nLogin item No* User Yes\r\nXPC service Yes User\r\nNo\r\n(Except in a very limited way using\r\nIOSurface)\r\nLaunch\r\nDaemon\r\nYes System No\r\nLaunch Agent Yes User Not recommended\r\n* Login items are started by the per-user instance of launchd , but it does not take any actions to manage them.\r\nFor more information about the system and user contexts, see Multiple User Environment Programming Topics.\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html\r\nPage 1 of 4\n\nLogin items\r\nLogin items are launched when the user logs in, and continue running until the user logs out or manually quits\r\nthem. Their primary purpose is to allow users to open frequently-used applications automatically, but they can also\r\nbe used by application developers. For example, a login item can be used to display a menu extra or to register a\r\nglobal hotkey.\r\nFor example, many to-do applications use a login item that listens for a global hotkey and presents a minimal UI\r\nallowing the user to enter a new task. Login items are also commonly used to display user interface items, such as\r\na floating clock or a timer, or to display an icon in the menu bar. .\r\nAnother example is a calendaring application with a helper application launched as a login item. The helper\r\napplication runs in the background and launches the main GUI application when appropriate to remind the user of\r\nupcoming appointments.\r\nFor information about how to create a login item, see Adding Login Items.\r\nXPC Services\r\nXPC services are managed by launchd and provide services to a single application. They are typically used to\r\ndivide an application into smaller parts. This can be used to improve reliability by limiting the impact if a process\r\ncrashes, and to improve security by limiting the impact if a process is compromised.\r\nWith traditional single-executable applications, if any part of the application crashes, the entire application\r\nterminates. By restructuring the application into a main process and services, the impact of a crash in a service is\r\nsignificantly less. The user can continue to work; the service that crashed gets relaunched. For example, an email\r\napplication can use an XPC service to handle communication with the mail server. Even if the service crashes,\r\ntemporarily interrupting communication with the server, the rest of the application remains usable.\r\nSandboxing allows you to specify a list of things your program is expected to do during normal operation. The\r\noperating system enforces that list, limiting the damage that can by done by an attacker. For example, a text editor\r\nmight need to edit files on disk that have been opened by the user, but it probably does not need to open arbitrary\r\nfiles in other locations or communicate over the network.\r\nYou can combine sandboxing with XPC services to provide privilege separation by splitting a complex\r\napplication, tool, or daemon into smaller pieces with well-defined functionality. Because of the reduced privileges\r\nof of each individual piece, any flaws are less exploitable by an attacker: none of the pieces run with the full\r\ncapabilities of the user. For example, an application that organizes and edits photographs does not usually need\r\nnetwork access. However, if it also allows users to upload photos to a photo sharing website, that functionality can\r\nbe implemented as an XPC service with network access and mediated access (or no access) to the file-system.\r\nFor information about how to create an XPC service, see Creating XPC Services.\r\nLaunch Daemons\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html\r\nPage 2 of 4\n\nDaemons are managed by launchd on behalf of the OS in the system context, which means they are unaware of\r\nthe users logged on to the system. A daemon cannot initiate contact with a user process directly; it can only\r\nrespond to requests made by user processes. Because they have no knowledge of users, daemons also have no\r\naccess to the window server, and thus no ability to post a visual interface or launch a GUI application. Daemons\r\nare strictly background processes that respond to low-level requests.\r\nMost daemons run in the system context of the system—that is, they run at the lowest level of the system and\r\nmake their services available to all user sessions. Daemons at this level continue running even when no users are\r\nlogged into the system, so the daemon program should have no direct knowledge of users. Instead, the daemon\r\nmust wait for a user program to contact it and make a request. As part of that request, the user program usually\r\ntells the daemon how to return any results.\r\nFor information about how to create a launch daemon, see Creating Launch Daemons and Agents.\r\nLaunch Agents\r\nAgents are managed by launchd , but are run on behalf of the currently logged-in user (that is, in the user\r\ncontext). Agents can communicate with other processes in the same user session and with system-wide daemons\r\nin the system context. They can display a visual interface, but this is not recommended.\r\nIf your code provides both user-specific and user-independent services, you might want to create both a daemon\r\nand an agent. Your daemon would run in the system context and provide the user-independent services while an\r\ninstance of your agent would run in each user session. The agents would coordinate with the daemon to provide\r\nthe services to each user.\r\nFor information about how to create a launch daemon, see Creating Launch Daemons and Agents.\r\nProtocols for Communicating with Daemons\r\nThere are four major communication mechanisms commonly used between daemons and their clients: XPC,\r\ntraditional client-server communications (including Apple events, TCP/IP, UDP, other socket and pipe\r\nmechanisms), remote procedure calls (including Mach RPC, Sun RPC, and Distributed Objects), and memory\r\nmapping (used underneath the Core Graphics APIs, among others).\r\nXPC is the easiest way to launch and communicate with your daemon. For details on implementing this\r\nmechanism, see Creating XPC Services and XPC Services API Reference.\r\nOther RPC (remote procedure call) mechanisms such as Distributed Objects should be avoided for communication\r\nacross security domain boundaries, for example a user process communicating with a system-level daemon,\r\nbecause this creates a security risk. They are appropriate only when you can be certain that both processes\r\ninvolved have the same level of privileges.\r\nIn most other cases, you should use a traditional client-server communication API. Code based on these APIs\r\ntends to be easier to understand, debug, and maintain than RPC or memory mapping designs. It also tends to be\r\nmore portable to other platforms than RPC-based code. For details on implementing using TCP/IP, read\r\nNetworking Overview.\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html\r\nPage 3 of 4\n\nMemory mapping requires complex management and represents a security risk if you are not careful about what\r\nmemory pages you share or if you do not sufficiently validate the shared data. You should use memory mapping\r\nonly if your client and daemon require a large amount of shared state with low latency, such as passing audio or\r\nvideo in real time. For details on implementing this mechanism, see SharedMemory.\r\nViewing the Currently Running Daemons\r\nIf you want to see the daemons currently running on your system, use the Activity Monitor application (located in\r\n/Applications/Utilities ). This application lets you view information about all processes including their\r\nresource usage. Figure 1-1 shows the Activity Monitor window and the process information.\r\nFigure 1-1  Processes shown in Activity Monitor\r\nSource: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html"
	],
	"report_names": [
		"DesigningDaemons.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434322,
	"ts_updated_at": 1775826758,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e41a337f57721007e82ddba1b4d11b0dd45859e5.pdf",
		"text": "https://archive.orkl.eu/e41a337f57721007e82ddba1b4d11b0dd45859e5.txt",
		"img": "https://archive.orkl.eu/e41a337f57721007e82ddba1b4d11b0dd45859e5.jpg"
	}
}