unload plist based on login

[#1]

Hello,

I would like to unload a plist based on user login or groups. I have
setup Casper with a policy that triggers on login, and I am triggering a
script. I get the following message in the logs:

"Script Result: launchctl: Error unloading:
com.m86security.authenticator"

The script language is:

#!/bin/sh
/bin/launchctl unload -w
/Library/LaunchAgents/com/m86security.authenticator.plist
exit 0

This script works if I run it from terminal on the local machine, or
straight from the command line in terminal. I am new to Macs, so any
help pointing to where I have gone wrong would be appreciated.

Thank you,

Darin Clausing
Computer Technician I
Computer Systems Department
Modesto City Schools
P: 209.550.3300 x5003
F: 209.576.4925

[rmanly]

I found this and the behavior seen seems to support it.

http://lists.macosforge.org/pipermail/launchd-dev/2007-November/000081.html
"Short summary pertinent to your symptoms:

- Root (uid 0) launchd loads jobs from LaunchDameons directories. Use
`sudo launchctl` to communicate with it.
- Per-user (uid 501) launchd loads jobs from LaunchAgents
directories. Use `launchctl` to communicate with it.
- Per-user launchd ignores the UserName key because it does not have
the privilege to execute as any other user than the current user.
- Per-user mach bootstrap is a sub-bootstrap of the root mach
bootstrap: agents can lookup daemons, but daemons cannot lookup agents.

- Kevin"

"launchctl list | grep m86" will show it running when logged in as that user
and opening up Terminal. The same command will not show when ssh'd into the
machine as Casper management user, or sudo -s'd to root or even su'd to the
user presently logged into the GUI.

It is probably better to just setup a group with different restrictions in
the m86 config. For example the Fac/Staff group here can go to many sites
that the students cannot.

Ryan M. Manly
Glenbrook High Schools

[sean]

The problem with trying to unload launch items at log in, is that the process may not be launched at the point of log in, so the script may run prior to the process being active. Of course, running the script manually in terminal will work, as log in has already occurred and the Agent is now running.

If I remember correctly, log in waits for log in scripts to complete before finishing log in, so you can't add a delay to your log in script. Someone please comment if I have misremembered this!

So to do what you want to achieve, I think you'll have to spawn another independent script in which you can add a delay.

I totally stand to be corrected.

Sean

[tlarkin]

This shouldn't be too hard, but you know if you use 8e6 filtering you can use LDAP credentials to base your filtering levels off of correct? Why not do that instead of writing a script? If you must write a script it can be done by checking group membership of the allowed/disallowed group and then execute the command based on desired output.