I use a standard user account for my daily tasks on Mac OS. Since upgrading to Snow Leopard I am asked to do the following when a program is run from within Xcode:
\
After you run:
sudo dscl . append /Groups/_developer GroupMembership <username>
per the answer above, you may still get prompted to enter in your own password:
We need authorization from an admin user to run the debugger. This will only happen once per login session.
What it really means is any _developer groupmember user so just your non-admin user/password will work here but to get rid of it completely (no prompts after a reboot) you'll also need to run:
sudo DevToolsSecurity -enable
(running it with sudo as an admin user/as root will make it so you can do it remotely without a gui password prompt)
You should add yourself to the Developer Tools group. The general syntax for adding a user to a group in OS X is as follows:
sudo dscl . append /Groups/<group> GroupMembership <username>
I believe the name for the DevTools group is _developer
.
Ned Deily's solution works perfectly fine, provided your user is allowed to sudo
.
If he's not, you can su
to an admin account, then use his dscl . append /Groups/_developer GroupMembership $user
, where $user is the username.
However, I mistakenly thought it did not because I wrongly typed in the user's name in the command and it silently fails.
Therefore, after entering this command, you should proof-check it. This will check if $user is in $group, where the variables represent respectively the user name and the group name.
dsmemberutil checkmembership -U $user -G $group
This command will either print the message user is not a member of the group
or user is a member of the group
.
Answer suggested by @Stacy Simpson:
We are struggling with the issue described in these threads and none of the resolutions seem to work:
As I'm new to SO, I cannot post in either thread. (The first one is actually closed and I disagree with the localization reasoning...)
Anyway, we created a work-around using AppleScript that folks may be interested in. The script below should be executed asynchronously prior to launching your automated test:
osascript <script name> <password> &
Here is the script:
on run argv
# Delay for 10 seconds as this script runs asynchronously to the automation process and is kicked off first.
delay 10
# Inspect all running processes
tell application "System Events"
set ProcessList to name of every process
# Determine if authentication is being requested
if "SecurityAgent" is in ProcessList then
# Bring this dialogue to the front
tell application "SecurityAgent" to activate
# Enter provided password
keystroke item 1 of argv
keystroke return
end if
end tell
end run
Probably not very secure, but it's the best work-around we've come up with to allow tests to run without requiring user intervention.
Hopefully, I can get enough points to post the answer; or, someone can unprotect this question. Regards.