#objective-c #cocoa #authentication #root
#objective-c #cocoa #аутентификация #root
Вопрос:
Я пытаюсь использовать BetterAuthorizationSample, а не использовать так называемый «вредоносный» способ использования setuid для получения привилегий root.
В настоящее время я использую AuthorizationCreate(); с проверкой подлинности, чтобы иметь root-доступ к изменению некоторых файлов, но меня несколько раздражает тот факт, что мне приходится постоянно вводить свой пароль при каждом запуске приложения.
Итак, я наткнулся на метод HelperTool от Apple, и я просто не могу в нем разобраться.
Я работаю с Cocoa уже пару месяцев, но это просто вне моей досягаемости, и все же мне это все еще нужно. Как бы я реализовал этот инструмент для выполнения простых задач с правами root?
Есть ли более простой способ использовать концепцию HelperTool, чтобы мои пользователи могли просто ввести свой пароль один раз, и это предоставило бы root-привилегии навсегда?
Комментарии:
1. Просто чтобы покончить с этим: BetterAuthorizationSample теперь является частью устаревшей библиотеки документации. Обратите внимание, когда был задан этот вопрос. Возможно, существует более современное решение, чем то, что реализует BetterAuthorizationSample.
Ответ №1:
«Современный» способ создать вспомогательный инструмент в Mac OS X — это отправить его как часть вашего приложения и использовать ServiceManagement
фреймворк для его развертывания. Ваши пользователи вводят свой пароль один раз, при развертывании инструмента. Это устанавливает его как launchd
задание; с этого момента вы используете любой механизм запуска по требованию, чтобы запустить помощник и заставить его выполнять работу за вас.
Обратите внимание, что в посте по указанной выше ссылке рекомендует вам защитить последующие вызовы помощник с разрешения служб эскалации, чтобы избежать произвольных привилегий, которые каждый может использовать. Похоже, что это несколько влияет на преимущество «пользователи могут просто ввести свой пароль один раз», хотя вы можете использовать AuthorizationRightSet()
для создания токена авторизации вашего приложения в базе данных политики, так что вы можете фактически определить, нужно ли пользователям предоставлять пароли при первом развертывании.
Пример кода из этого поста находится на GitHub и демонстрирует использование ServiceManagement
для развертывания вспомогательного средства и служб авторизации для контроля доступа к нему.
Комментарии:
1. Я подумал, что вмешаюсь и просто укажу, что ничего из этого не сработает, если вы изолируете свое основное приложение. SMJobBless() завершится ошибкой. Последнее, что я слышал от Куинна, он работал над обновленным примером, который подходит для разработчиков, желающих отправлять изолированные приложения за пределы App Store, но при этом иметь возможность выполнять такого рода функции.