[launchd-dev] User Deamon

James Bucanek subscriber at gloaming.com
Mon Nov 26 16:20:20 PST 2007


Welcome,

I was invited to bring this thread here by Quinn. My apologies 
if you've seen bits and pieced of this thread before; it's 
traveled around the Cocoa, Carbon, and MacNetworkProg lists 
before landing here.

I'm developing a backup and document archiving solution 
(<http://www.qrecall.com/> -- not an ad, just for reference).

The program provides "actions" that can be scheduled to run at 
regular intervals or in response to certain events. These 
actions should be performed whether the user is logged in or 
out. In fact, actions can be scheduled to run only when the user 
is logged out or because the user logged out.

There is a scheduler process which is responsible for managing 
all of this. The scheduler works on behalf of a single user. 
(Other users may have their own schedule/scheduler.) For 
security, the scheduler runs under the UID of that user.

So, what I have is a process that

- Needs to start up when the system boots and runs until the 
system shuts down, independent of whether the user is logged in 
or not.

- Runs as a single user (not as root) without any special privileges.

- Can be installed and removed without requiring administrative authorization.

In effect, I need a "User Daemon" -- a class of process that 
launchd does not provide.

I was simulating this (pretty well) using crontab. The crontab 
will allow non-admin users to install a cronjob that runs 
periodically and independently of their login session. 
Unfortunately, recent versions of Tiger and Leopard have become 
downright hostile towards user cronjobs, sending them SIGKILL 
signals whenever the user is logged out (without even the 
courtesy of a SIGTERM first!).

I'm now simulating this by installing a system-wide daemon for 
each user (/Library/LaunchDaemons/QRecallScheduler501.plist, 
.../QRecallScheduler502.plist, etc.). Each daemon is configured 
to run as that user (via the UserName property). But this 
requires administrative privileges to install/uninstall a 
non-privileged process. Beyond being annoying, it limits the 
usefulness of the application for non-admin users. And in the 
pit of my stomach, I feel that it presents a security hole.

I'm basically just throwing this out to the launchd team for 
comments, which might result in filing a feature request.

I also understand some of the potential problems in implementing 
user daemons. (For example, the logical place to place a user 
daemon configuration file would be in ~/Library/LaunchDaemons, 
but that obviously won't work with FileVault or users who mount 
their home folder over a network.) However, there are also 
potential solutions to some of these and there's also the 
principle that one shouldn't necessarily eliminate a feature 
just because 0.1% of the users can't use it. ;)

Any thoughts?

-- 
James Bucanek



More information about the launchd-dev mailing list