Skip navigation.
 
mlRe: Cocoa daemon
FROM : Charles Srstka
DATE : Fri Aug 01 21:52:29 2008

On Aug 1, 2008, at 2:28 PM, Jens Alfke wrote:

> That class is in the AppKit framework. Daemons must not link against 
> AppKit, or any other framework, like HLTB, that would connect to the 
> window server. (I believe the big Daemons-and-Agents technote has a 
> list of what frameworks are OK.)
>
> The reason is that a daemon runs at a lower level of the system than 
> the window server or a user login session. Daemons should not 
> generally perform per-user functions because they don't run as a 
> real user (typically they're either root, or a special-purpose 
> pseudo-user like 'www'.)
>
> If you want to run a background process on behalf of a particular 
> login session, use an agent. This is much like writing a daemon 
> except that you put the launchd plist in ~/Library/LaunchAgents or /
> Library/LaunchAgents.
>
> Agents should also ideally not link against AppKit or connect to the 
> WindowServer; this helps limit the system resources they use. If you 
> really need to have a UI, such as an NSStatusItem, you should 
> package your daemon in a .app bundle, using the LSUIElement 
> Info.plist key so that it won't show up in the Dock.
>
> Again, the technote describes all of this. It's definitely required 
> reading if you're writing any kind of daemon/agent/background process.


As an illustration of the problems that can occur if you connect a 
daemon to the window server, there was a security hole until last 
night's security update that allowed any non-privileged app to send a 
"do shell script" command to a Cocoa app running as root, and run any 
arbitrary terminal command as root *without* using sudo, 
AuthorizationExecuteWithPrivileges(), or knowledge of any admin 
password. If one Cocoa app on the system was running as root, 
basically every process on the system that could send AppleScripts 
also had root access.

That particular bug's been fixed now (assuming you've downloaded and 
installed the latest security update), but there's no saying that 
similar not-yet-discovered issues won't crop up in the future, causing 
your daemon to be a vehicle for exploits. Better to make daemons link 
against Foundation only.

Charles

Related mailsAuthorDate
mlCocoa daemon Ivan C Myrvold Aug 1, 12:11
mlRe: Cocoa daemon Negm-Awad Amin Aug 1, 12:32
mlRe: Cocoa daemon Ivan C Myrvold Aug 1, 14:17
mlRe: Cocoa daemon Geoff Beier Aug 1, 14:24
mlRe: Cocoa daemon Daniel Richman Aug 1, 16:28
mlRe: Cocoa daemon Jens Alfke Aug 1, 21:28
mlRe: Cocoa daemon Charles Srstka Aug 1, 21:52
mlRe: Cocoa daemon Negm-Awad Amin Aug 2, 08:58