[launchd-dev] User Deamon
Dave Zarzycki
zarzycki at apple.com
Tue Nov 27 11:02:28 PST 2007
On Nov 27, 2007, at 10:59 AM, Dave Zarzycki wrote:
> At the moment user-agents cannot be launched at boot. Otherwise the
> solution would be "perfect" (with the exception of FileVault and AFP
> home directories, but that is a different problem). Please file a
> bug/enhancement-request on that.
Er... With 'that' being the user-agents launch-at-boot problem...
There isn't much I can do about the FileVault case...
>
>
> I think your configuration file per user is the next best
> alternative in the Leopard timeframe.
>
> Good luck,
>
> davez
>
>
>
> On Nov 26, 2007, at 4:20 PM, James Bucanek wrote:
>
>> 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
>>
>> _______________________________________________
>> launchd-dev mailing list
>> launchd-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo/launchd-dev
>
> _______________________________________________
> launchd-dev mailing list
> launchd-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/launchd-dev
More information about the launchd-dev
mailing list