Авторизуйте разработчика без прав администратора в Xcode / Mac OS - PullRequest
106 голосов
/ 03 декабря 2009

Я использую стандартную учетную запись пользователя для своих ежедневных задач в Mac OS. После обновления до Snow Leopard меня просят сделать следующее при запуске программы из Xcode:

«Введите имя и пароль пользователя в группе« Инструменты разработчика », чтобы разрешить доступ к Инструментам разработчика для внесения изменений»

Хотя я знаю имя пользователя и пароль администратора, это раздражает (хотя требуется только один раз для входа в систему).

Для доступа к инструментам разработчика требуются права на "system.privilege.taskport.debug" из приложения gdb-i386-apple-darwin.

Как лучше всего обойти это?

Ответы [ 10 ]

131 голосов
/ 03 декабря 2009

Вам необходимо добавить имя пользователя OS X в группу _developer. См. Сообщения в этой теме для получения дополнительной информации. Следующая команда должна сделать трюк:

sudo dscl . append /Groups/_developer GroupMembership <username>
23 голосов
/ 21 февраля 2012

Наконец, я смог избавиться от него, используя DevToolsSecurity -enable на Терминале. Благодаря @ joar_at_work !

К вашему сведению : я нахожусь на Xcode 4.3 и нажал кнопку отключить при первом запуске, не спрашивайте почему, просто предположите, что моя собака заставила меня это :)

9 голосов
/ 03 декабря 2009
$ dseditgroup -o edit -u <adminusername> -t user -a <developerusername> _developer
8 голосов
/ 03 декабря 2009

Вы должны добавить себя в группу Инструменты разработчика. Общий синтаксис для добавления пользователя в группу в OS X выглядит следующим образом:

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

Я считаю, что название группы DevTools _developer.

3 голосов
/ 11 февраля 2014

Решение Неда Дейли работает отлично, при условии, что вашему пользователю разрешено sudo.

Если нет, вы можете su войти в учетную запись администратора, а затем использовать его dscl . append /Groups/_developer GroupMembership $user, где $ user - имя пользователя.

Однако я ошибочно подумал, что это не так, потому что я неправильно ввел имя пользователя в команду, и он молча терпит неудачу. Поэтому после ввода этой команды вы должны проверить ее. Это проверит, находится ли $ user в $ group, где переменные представляют соответственно имя пользователя и имя группы.

dsmemberutil checkmembership -U $user -G $group

Эта команда напечатает сообщение user is not a member of the group или user is a member of the group.

2 голосов
/ 19 апреля 2013

Ответ, предложенный @Stacy Simpson:

Мы боремся с проблемой, описанной в этих темах, и ни одно из разрешений не работает:

Поскольку я новичок в SO, я не могу писать ни в одной теме. (Первый фактически закрыт, и я не согласен с рассуждениями о локализации ...)

В любом случае, мы создали обходной путь, используя AppleScript, который может заинтересовать людей. Сценарий, приведенный ниже, должен выполняться асинхронно до запуска вашего автоматического теста:

osascript <script name> <password> &

Вот сценарий:

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

Вероятно, не очень безопасный, но это лучший обходной путь, который мы придумали, чтобы тесты могли выполняться без вмешательства пользователя.

Надеюсь, я смогу набрать достаточно очков, чтобы опубликовать ответ; или кто-то может снять этот вопрос с защиты. С уважением.

1 голос
/ 17 января 2014

Вот лучшее решение из
Mac OS X хочет использовать системную цепочку для ключей при компиляции проекта

  1. Открыть доступ к связке ключей.
  2. В верхнем левом углу разблокируйте брелок (если он заблокирован).
  3. Выберите системную связку ключей из левого верхнего угла.
  4. Найдите свой сертификат распространения и щелкните треугольник раскрытия.
  5. Дважды щелкните «Закрытый ключ» под своим сертификатом распространения.
  6. Во всплывающем окне перейдите на вкладку «Контроль доступа».
  7. Выберите «Разрешить всем приложениям доступ к этому элементу».
  8. Сохранить изменения.
  9. Закройте все окна.
  10. Запустите приложение.
1 голос
/ 25 марта 2010

Я на снежном барсе, и этот мне не совсем помог. Но сработала следующая процедура:

  1. Сначала добавили еще одну учетную запись с правами администратора, отметив «Разрешить пользователю управлять этим компьютером» в разделе «Учетные записи», например, учетная запись с именем пользователя test
  2. Зарегистрировался в тесте аккаунт
  3. Запустил Xcode, скомпилировал и запустил мой проект iPhone. Все в порядке, не было выдано ошибок, связанных с разрешениями
  4. Выйти из теста Аккаунт
  5. Войдите в систему с другой учетной записью, имеющей права администратора
  6. Забрал права администратора из учетной записи test , сняв галочку с «Разрешить пользователю управлять этим компьютером» в разделе «Учетные записи»
  7. Вы снова вошли в учетную запись test
  8. Удалил каталог проекта iPhone и снова извлек из хранилища (в моем случае svn)
  9. Запустил Xcode, скомпилировал и запустил проект. Я не получил никаких ошибок, и приложение хорошо работало в iPhone Simulator.
0 голосов
/ 08 марта 2013

Для меня я нашел предложение в следующей ветке помогло:

Стоп "доступ средств разработчика должен взять под контроль другой процесс для продолжения отладки" предупреждение

Было предложено запустить следующую команду в приложении Terminal :

sudo /usr/sbin/DevToolsSecurity --enable
0 голосов
/ 16 августа 2012

После запуска:

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

за ответ выше, вы можете все же получить запрос на ввод собственного пароля:

Нам нужна авторизация от администратора для запуска отладчика. Это произойдет только один раз за сеанс входа в систему.

Что на самом деле означает любой _developer пользователь группы, так что здесь будет работать только ваш пользователь / пароль, не являющийся администратором, но чтобы полностью избавиться от него (без запросов после перезагрузки), вам также потребуется бежать:

sudo DevToolsSecurity -enable

(запуск его с помощью sudo в качестве пользователя-администратора / с правами root сделает это, так что вы можете сделать это удаленно без запроса пароля графического интерфейса)

...