March 2011 - launchd-dev - lists.macosforge.org

Install and load a launch daemon without a reboot
by Jeremy Reichman 20 Oct '11

20 Oct '11

What is considered the current best practice for installing and then running a launch daemon, while avoiding a reboot? I didn't see exactly what I was looking for in my list archive or found it in any documentation on installation packages. I have reviewed TN2083, specifically the "Starting a Daemon" section. That answers most of my question but it would be helpful to have confirmation. Besides the conditions listed in TN2083, I'd like my installer to behave well when installed to a disk other than the current startup volume. I need to target Mac OS X 10.5 and 10.6. It looks as if I'd need to test for the right conditions and then run launchctl to load the property list. Roughly -- not production code -- it looks like I'd need a postinstall and postupgrade script to do the following: # Test if the destination volume for the payload and the root volume path are the same if [ "$3" = "$4" ] ; then # Quick test to see if the script is run by root if [ `/usr/bin/whoami` = "root" ] ; then /bin/launchctl load "$3/Library/LaunchDaemons/com.vendor.launchdaemon.plist" fi fi exit 0 Is that the right approach? Thanks! -- Jeremy

7 22

Starting/Stoping Apache HTTPD outside System Preferences
by Luke Scott 30 Mar '11

30 Mar '11

The plist file for the included version of Apache HTTPD contains a key called SHAuthorizationRight which is set to system.preferences. Because of this key System Preferences can start/stop the service without being root. I cannot find any documentation on this key. Is there any way to do this with my own plist and application? Basically I want to role my own version of httpd and create a launchd plist and be able to start/stop the service from a menu driven application. It needs to be able to do this without escalating it's privileges or entering a password. If there isn't a way, what are my (secure) alternatives, without entering a password, if any? Anyone know? Thanks, Luke

2 2

Re: [launchd-dev] Appropriate LaunchDaemon filesystem locations
by Quinn "The Eskimo!" 07 Mar '11

07 Mar '11

On 6 Mar 2011, at 23:11, Michael_google gmail_Gersten wrote: > So why not /Library/AdditionalHelperTools? > > Or, better: > > /Library/HelperTools/{Privileged,Additional} > > Or > > /Library/ProtectedAppFiles/{AppName} It's not that it's hard to come up with good approaches, but that there's no comprehensive guidance from Apple on this issue. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware

1 0

Appropriate LaunchDaemon filesystem locations
by Jeremy Reichman 01 Mar '11

01 Mar '11

TN2083 states: > When you install your daemon, make sure that you set the file system > permissions correctly. Apple recommends that daemons be owned by root, have an > owning group of wheel, and use permissions 755 (rwxr-xr-x) for executables and > directories, and 644 (rw-r--r--) for files. In addition, every directory from > your daemon up to the root directory must be owned by root and only writable > by the owner (or owned by root and sticky). If you don't do this correctly, a > non-admin user might be able to escalate their privileges by modifying your > daemon (or shuffling it aside). The technote isn't specific about which existing filesystem locations are appropriate for storing launchdaemons' executables. Does "writable by owner" mean both the individual owner and group owner? I interpret the recommendation above to mean the individual owner and not the group owner, but that may not be what is intended. What standard locations are considered appropriate for launchdaemons? Files in application bundles in /Applications probably won't meet the recommendations above, because /Applications is owned by root:admin and writable by both as a default. Applications are often installed by drag and drop, and so individual apps won't even have the stricter ownership that the parent /Applications folder will have. Subfolders in /Library/Application Support in the local domain are also unable to meet these recommendations. The /Library folder is owned and writable by admin, even though it is also owned by root and sticky. /Library/Applications Support is itself owned by root and admin, and is again writable by both. As long as I'm asking, is there any functional or security difference between a launchdaemon plist with 755 or 644 permissions. I almost exclusively see them with 644 permissions (and root:wheel ownership) but occasionally come across one that is 755. Thanks! -- Jeremy

3 2