授权 Xcode/Mac 操作系统的非管理员开发者

小开

最佳答案

You need to add your macOS user name to the _developer group. See the posts in this thread for more information. The following command should do the trick:

sudo dscl . append /Groups/_developer GroupMembership <username>

小开

$ dseditgroup -o edit -u <adminusername> -t user -a <developerusername> _developer

小开

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.

小开

I am on Snow Leopard and this one didn't quite work for me. But the following procedure worked:

First added another account with admin privileges by ticking "Allow user to administer this computer" under Accounts, for example an account with username test
Logged into the test account
Launched Xcode, compiled and ran my iPhone project. All ok, no errors were thrown related to permissions
Logged out of the test account
Logged in with the another account having admin privileges
Took away the admin priviliges from the test account by removing the tick from "Allow user to administer this computer" under Accounts
Logged back into the test account
Deleted the iPhone project directory and again checked out from the repository (in my case svn)
Launched Xcode, compiled and ran the project. I didn't get any errors and the App ran well in the iPhone Simulator.

小开

Finally, I was able to get rid of it using DevToolsSecurity -enable on Terminal. Thanks to @joar_at_work!

FYI: I'm on Xcode 4.3, and pressed the disable button when it launched for the first time, don't ask why, just assume my dog made me do it :)

小开

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)

小开

For me, I found the suggestion in the following thread helped:

Stop "developer tools access needs to take control of another process for debugging to continue" alert

It suggested running the following command in the Terminal application:

sudo /usr/sbin/DevToolsSecurity --enable

小开

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.

小开

Here is a better solution from
Mac OS X wants to use system keychain when compiling the project

Open Keychain Access.

In the top-left corner, unlock the keychain (if it is locked).

Choose the System keychain from the top-left corner.

Find your distribution certificate and click the disclosure triangle.

Double-click ‘Private key’ under your distribution certificate.

In the popup, go to the Access Control tab.

Select ‘Allow all applications to access this item’.

Save the changes.

Close all windows.

Run the application.

小开

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.