LaunchDaemon to run at every logon?

[tlarkin]

in 10.5 I think launchd owns all, one daemon to rule them all if you want to get geeky in a Tolkien sort of way.

I think they left legacy support in 10.5 but I would try to get the official recommended way to work first, but that is just me I suppose.

[biovizier]

Support may be on the way out but for now, the login window hooks do appear to be officially supported as the article linked above has instructions for "10.3, 10.4, or later" and lists 10.5 in the "Products Affected" section.

The impression I get from the 'launchd' documentation is that by default, a plist in "/Library/LaunchDaemons" is loaded as "root" during startup, but one in "/Library/LaunchAgents" loads at login but as the user logging in. If a process set in motion from such a plist file is examined with "Activity Monitor", its parent process appears to be the user's launchd process.

The documentation also suggests that the user a job runs as can be changed by adding a 'UserName' property to the plist file, but this only seems to apply if the logging in user is "root", which defeats the purpose (in the context of this thread). Perhaps this feature hasn't been fully implemented yet, although I'm not sure how it could be accomplished at all if a launch agent is something spawned by the user's 'launchd' process.

I suppose we should be thankful that the login window hooks are still around at all, given Apple's penchant for killing things before their replacements are ready to take over...

Edit: The Leopard version of the man page says UserName only applies if the launchd process is running as "root", so it normally will not apply to launch agents at all (unless the user logging in is "root"), and indeed the logs show the key being ignored. So to me, it seems like it is working as designed and it seems a launch agent can replace (and add capabilities beyond) a login item, but isn't designed to substitute for a login hook.

[tw]

Quote: Originally Posted by kaptagat Still the same. It is beginning to look like that user agents don't run as root. Thanks TW, I had previously tried that option and it does work but I didn't really want something running all the time however it looks like I will have to go with that option and run it as a launchdaemon. Shame that Mike Bombich has stopped developing his loginwindowmanager because I found it a very useful piece of software.

well, technically speaking, it's not running all the time - the script would only launch when there is a change in the folder. but having said that, I just looked at the man page for launchd.plist, and it says the following (at the bottom):

Quote: FILES ~/Library/LaunchAgents Per-user agents provided by the user. /Library/LaunchAgents Per-user agents provided by the administrator. /Library/LaunchDaemons System wide daemons provided by the administrator.

that would seem to imply that moving the plist from the /Library/LaunchDaemons folder to the /Library/LaunchAgents folder would do what you want. or have you tried that?

[tlarkin]

Quote: Originally Posted by tw .... /Library/LaunchDaemons folder to the /Library/LaunchAgents folder would do what you want. or have you tried that?

I stated that several posts ago....Guess I should have been more clear.

[tw]

Quote: Originally Posted by tlarkin I stated that several posts ago....Guess I should have been more clear.

no, I think I should have read more carefully; my bad. actually, I do think this is the solution to the problem - put the plist in the /Library/LaunchAgents folder, but have it call a script that runs as root (rather than running the command form the ProgramArguments key). should solve both the login and permissions requirements...

[kaptagat]

Having the plist call a script does not work either, same "operation not permitted" in the system.log. I am going to look into using a loginwindow hook, which is in fact what Mike Bombich's loginwindowmanager is a nice friendly GUI for.

[tw]

Quote: Originally Posted by kaptagat Having the plist call a script does not work either, same "operation not permitted" in the system.log. I am going to look into using a loginwindow hook, which is in fact what Mike Bombich's loginwindowmanager is a nice friendly GUI for.

really? are you sure you have the permissions on the script set correctly (it should be owned as root and executable by everyone, I think...).

[tlarkin]

Quote: Originally Posted by tw really? are you sure you have the permissions on the script set correctly (it should be owned as root and executable by everyone, I think...).

this is what I did and it worked for me

chown root:wheel /usr/sbin/myscript.sh

chmod +x /usr/sbin/myscript.sh

Then in the plist, which I called org.myscript.kckps (my organization) I had it execute the path of

/usr/sbin/myscript.sh

It worked for me.

[kaptagat]

Well I just don't get this. The script is called 777_shared_folder. It is in /usr/sbin and its permissions are :-
-rwxr-xr-x 1 root wheel 47 11 Nov 09:15 /usr/sbin/777_shared_folder

The plist, in the LaunchAgents folder, is :-
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>chmod777_users_shared</string>
<key>ProgramArguments</key>
<array>
<string>/usr/sbin/777_shared_folder</string>
</array>
<key>QueueDirectories</key>
<array/>
<key>RunAtLoad</key>
<true/>
<key>StartInterval</key>
<integer>0</integer>
<key>WatchPaths</key>
<array/>
</dict>
</plist>
yet when it runs at login I still see this in the system log:-

Nov 11 09:29:29 macintosh-2 chmod777_users_shared[972]: chmod: /Users/Shared/a.rtf: Operation not permitted
Nov 11 09:29:29 macintosh-2 chmod777_users_shared[972]: chmod: /Users/Shared/aa.rtf: Operation not permitted
Nov 11 09:29:29 macintosh-2 chmod777_users_shared[972]: chmod: /Users/Shared/aaa.rtf: Operation not permitted
Nov 11 09:29:29 macintosh-2 chmod777_users_shared[972]: chmod: /Users/Shared/aaaa.rtf: Operation not permitted
Nov 11 09:29:29 macintosh-2 com.apple.launchd[65] (chmod777_users_shared[972]): Exited with exit code: 1

When I drag the script from its folder into a terminal window and press return, I get the same errors, but if I put sudo in front, it asks for the password, and then works fine.

[biovizier]

As I understand it, this is the situation:

Launch daemons:
/System/Library/LaunchDaemons Mac OS X System wide daemons.
/Library/LaunchDaemons System wide daemons provided by the administrator.
- "System"
- Load at boot
- Run as "root"

Launch agents:
/System/Library/LaunchAgents Mac OS X Per-user agents.
/Library/LaunchAgents Per-user agents provided by the administrator.
~/Library/LaunchAgents Per-user agents provided by the user.
- "per-user"
- Load at login
- Run as the user logging in

In a default 10.5 setup, the ownership of a script doesn't matter - it will run as the user calling it, so a script called by a launch agent will run as the user loggiing in.

From the 'man' page of 'chmod':
"Only the owner of a file or the super-user is permitted to change the mode of a file."

Therefore, a launch agent will only ever be able to 'chmod' files the logging in user already owns. Exceptions including if the logging in user is "root", or if the command being called by the launch agent is setuid or otherwise able to elevate its privileges. If the script attempts to use 'chmod' on a file not owned by the logging in user, the error is "Operation not permitted".

[kaptagat]

Thanks biovizier, that does appear to be the case. Just wondering how Mr. tlarkin got his to work. So it seems that if one wants a script to run as root for every logon, then one has to use a loginwindow hook or hope that Mr. Bombich updates his loginwindow manager to 10.5.

Thanks for all replies.

[biovizier]

It's hard to say without seeing the script, but I would speculate that the nature of the script being called might have something to do with it. For example, turning on Airport and connecting to a "preferred network" were mentioned (back in post #17), which suggests a predefined network "location" exists for the "preferred network".

The initial setup or making changes to the configuration of network locations require "root" level privileges. However, note that switching between pre-existing network locations can be accomplished with just "user" level privileges because '/usr/sbin/scselect', invoked directly or via the "" > "Location" menu, is owned by root and 'setuid'. If the script uses 'scselect', that might be one reason a launch agent would be sufficient to make system level changes that would otherwise require "root" privileges...

[tlarkin]

Sorry for the confusion. I actually wrote a shell script like this

#!/bin/sh

echo 'this is just an example'

done

Then saved it as myscript.sh and pushed out it out via casper policy at my work into every user's laptop under the path /usr/sbin/myscript.sh

Then I made a launchd item that ran at boot up that looked like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>KeepAlive</key>
	<false/>
	<key>Label</key>
	<string>com.osxhints.myscript</string>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/sbin/myscript</string>
	</array>
	<key>QueueDirectories</key>
	<array/>
	<key>RunAtLoad</key>
	<true/>
	<key>WatchPaths</key>
	<array/>
</dict>
</plist>

Last I saved the com.osxhints.myscript.plist into /Library/LaunchDaemons and let it roll out. To test it worked I rebooted a machine and ran launchctl list | grep com.osxhints.myscript to make sure it was running after a reboot.

[tw]

Quote: Originally Posted by kaptagat Well I just don't get this. The script is called 777_shared_folder. It is in /usr/sbin and its permissions are :- -rwxr-xr-x 1 root wheel 47 11 Nov 09:15 /usr/sbin/777_shared_folder

ok, a quick google search leads me to believe that you might need to set the permissions on the script to '-rws--x--x' (chmod 4711 /usr/sbin/777_shared_folder), with root as owner. the leading '4' corresponds to the 's' - it's the set UID bit. basically that tells the system to run the script as the script owner (in this case root) regardless of who the current user running it is. you might need to set it to 4755, instead (I'm not sure if read permisiions are required or not).

Quote: Originally Posted by kaptagat The plist, in the LaunchAgents folder, is...:- <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>chmod777_users_shared</string> <key>ProgramArguments</key> <array> <string>/usr/sbin/777_shared_folder</string> </array> <key>QueueDirectories</key> <array/> <key>RunAtLoad</key> <true/> <key>StartInterval</key> <integer>0</integer> <key>WatchPaths</key> <array/> </dict> </plist>

you have extra keys in the plist: QueueDirectories, WatchPaths, and StartInterval. the first two are probably innocuous, but might not be; the last is odd - it seems to tell launchd to run the script every 0 seconds. I'd remove them all just on principle

[tw]

God help me - when did I turn into a unix geek?

[tlarkin]

Those last three lines are generated by default from Lingon, which is why my example has them. I don't think they can hurt to be honest.

God can't help you man, you can only find salvation through the shell!

[tw]

Quote: Originally Posted by tlarkin God can't help you man, you can only find salvation through the shell!

rm -f *.hope

[tlarkin]

Quote: Originally Posted by tw rm -f *.hope

I'm slightly disappointed, real Unix geeks would have used the full path to rm.....

Though I must admit every time I see this, I laugh.

/usr/sbin/chown -R us ./base

[tw]

lol - yeah, and the difference between dating and marriage:

dating: /bin/chmod 755 *.*
marriage: /bin/chmod 607 *.*

[Solarusdude]

Oh man, it's not good when you're able to understand those UNIX jokes in under 5 seconds.