web-dev-qa-db-fra.com

Autoriser un développeur non administrateur dans Xcode / Mac OS

J'utilise un compte d'utilisateur standard pour mes tâches quotidiennes sous Mac OS. Depuis la mise à niveau vers Snow Leopard, je suis invité à effectuer les opérations suivantes lorsqu'un programme est exécuté à partir de Xcode:

"Tapez le nom et le mot de passe d'un utilisateur du groupe" Outils de développement "pour permettre à l'accès aux outils de développement d'apporter des modifications"

Bien que je connaisse le nom d’utilisateur/mot de passe de l’administrateur, c’est ennuyeux (même s’il n’est requis qu’une fois par connexion).

L'accès aux outils pour les développeurs demande des droits sur "system.privilege.taskport.debug" à partir de l'application gdb-i386-Apple-darwin.

Quel est le meilleur moyen de contourner cela?

xcodemacososx-snow-leopardprivilegesdscl
106
Andrew Cain

Vous devez ajouter votre nom d'utilisateur OS X au _developer groupe. Voir les articles dans ce fil pour plus d'informations. La commande suivante devrait faire l'affaire:

Sudo dscl . append /Groups/_developer GroupMembership <username>
131
Ned Deily

Finalement, j'ai pu m'en débarrasser en utilisant DevToolsSecurity -enable sur le terminal. Merci à @ joar_at_work !

[~ # ~] fyi [~ # ~] : je suis sur Xcode 4.3, et j'ai appuyé sur le désactiver lorsqu’il a été lancé pour la première fois, ne demandez pas pourquoi, supposez simplement que mon chien m’a fait le faire :)

23
chunkyguy
$ dseditgroup -o edit -u <adminusername> -t user -a <developerusername> _developer
9
cdespinosa

Vous devez vous ajouter au groupe Outils de développement. La syntaxe générale pour ajouter un utilisateur à un groupe sous OS X est la suivante:

Sudo dscl . append /Groups/<group> GroupMembership <username>

Je crois que le nom du groupe DevTools est _developer.

8
phoebus

La solution de Ned Deily fonctionne parfaitement, à condition que votre utilisateur soit autorisé à Sudo.

S'il ne l'est pas, vous pouvez su sous un compte administrateur, puis utilisez son dscl . append /Groups/_developer GroupMembership $user, où $ utilisateur est le nom d'utilisateur.

Cependant, j'ai pensé à tort que ce n'était pas le cas, car j'ai mal saisi le nom de l'utilisateur dans la commande et il échoue silencieusement.

Par conséquent, après avoir entré cette commande, vous devez la vérifier. Ceci vérifiera si $ utilisateur est dans $ groupe, où les variables représentent respectivement le nom d'utilisateur et le nom du groupe.

dsmemberutil checkmembership -U $user -G $group

Cette commande va soit imprimer le message user is not a member of the group ou user is a member of the group.

3
Kheldar

Réponse suggérée par @Stacy Simpson:

Nous sommes aux prises avec le problème décrit dans ces discussions et aucune des résolutions ne semble fonctionner:

Comme je suis nouveau sur SO, je ne peux pas publier dans aucun fil. (Le premier est en fait fermé et je ne suis pas d'accord avec le raisonnement concernant la localisation ...)

Quoi qu'il en soit, nous avons créé une solution de contournement à l'aide d'AppleScript qui pourrait intéresser les gens. Le script ci-dessous doit être exécuté de manière asynchrone avant le lancement de votre test automatisé:

osascript <script name> <password> &

Voici le 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

Probablement pas très sécurisé, mais c’est la meilleure solution que nous ayons mise au point pour permettre l’exécution de tests sans intervention de l’utilisateur.

Si tout va bien, je peux obtenir assez de points pour poster la réponse; ou, quelqu'un peut déprotéger cette question. Cordialement.

2
Martin Turjak

Voici une meilleure solution de
Mac OS X veut utiliser le trousseau système lors de la compilation du projet

  1. Ouvrir le trousseau d'accès.
  2. Dans le coin supérieur gauche, déverrouillez le trousseau (s’il est verrouillé).
  3. Choisissez le trousseau Système dans le coin supérieur gauche.
  4. Recherchez votre certificat de distribution et cliquez sur le triangle d’affichage.
  5. Double-cliquez sur ‘Clé privée’ sous votre certificat de distribution.
  6. Dans la fenêtre contextuelle, accédez à l'onglet Contrôle d'accès.
  7. Sélectionnez "Autoriser toutes les applications à accéder à cet élément".
  8. Enregistrez les modifications.
  9. Fermez toutes les fenêtres.
  10. Lancer l'application.
1
Raj

Je suis sur Snow Leopard et celui-ci n'a pas vraiment fonctionné pour moi. Mais la procédure suivante a fonctionné:

  1. Vous avez d’abord ajouté un autre compte doté de privilèges d’administrateur en cochant la case "Autoriser l’utilisateur à administrer cet ordinateur" sous Comptes, par exemple un compte avec nom d’utilisateur test
  2. Connecté au compte test
  3. Lancement de Xcode, compilation et exécution de mon projet iPhone. Tout va bien, aucune erreur liée aux autorisations n'a été générée
  4. Déconnecté du compte test
  5. Connecté avec un autre compte ayant des privilèges d'administrateur
  6. Supprimez les privilèges administrateur du compte test en décochant la case "Autoriser l'utilisateur à administrer cet ordinateur" sous Comptes
  7. Reconnecté au compte test
  8. Suppression du répertoire du projet iPhone et extraction à nouveau du référentiel (dans mon cas, svn)
  9. Lancement de Xcode, compilation et exécution du projet. Je n'ai pas eu d'erreur et l'application a bien fonctionné dans le simulateur iPhone.
1
Naveen Kansara

Après avoir couru:

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

selon la réponse ci-dessus, vous pouvez toujours être invité à entrer votre propre mot de passe:

Nous avons besoin de l'autorisation d'un utilisateur administrateur pour exécuter le débogueur. Cela ne se produira qu'une fois par session de connexion.

Ce que cela signifie réellement, c’est tout _ développeur utilisateur du groupe, de sorte que seul votre mot de passe/utilisateur non-administrateur fonctionnera ici, mais pour vous en débarrasser complètement (aucune invite après le un redémarrage), vous aurez également besoin d'exécuter:

Sudo DevToolsSecurity -enable

(l'exécuter avec Sudo en tant qu'administrateur/en tant que root vous permettra de le faire à distance sans invite de mot de passe gui)

0
timofei7

Pour moi, j'ai trouvé la suggestion dans le fil suivant:

Stop "alerte des outils de développement doit prendre le contrôle d'un autre processus pour que le débogage continue" alerte

Il a suggéré d'exécuter la commande suivante dans l'application Terminal :

Sudo /usr/sbin/DevToolsSecurity --enable
0
Mike Gledhill