[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