February 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

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

upgrading a helper tool with SMJobBless
by Richard Brown 16 Feb '11

16 Feb '11

The SMobBless documentation specifies that '[t]he helper tool must have an embedded Info.plist containing an "SMAuthorizedClients" array of strings. Each string is a textual representation of a code signing requirement describing a client which is allowed to add and remove the tool.' Let's say I write an application MyApp with a privileged helper tool MyTool (com.mydomain.MyTool). MyApp 1.0 satisfies MyTool 1.0's codesigning requirement. Later, I release version 2.0, but I've had to change something about MyApp, and MyApp 2.0 no longer satisfies MyTool 1.0's requirement. What will happen when I try to upgrade MyTool using SMJobBless? Does an upgrade count as a remove+add, or will the upgrade succeed? If this will fail, what is a workaround? I will file an enhancement request based on the answer, either for clearer documentation (saying that upgrading in this manner is OK), or for very clear warnings about this case and to consider the SMAuthorizedClients requirements very carefully. Thanks, RB -- Richard Brown QuantumCheese Coding rabrown(a)quantumcheese.com

1 0