Удаление элементов, установленных пользователем .app, когда пользователь удаляет его, включая помощники SMJobBless.

Question

.

. Краткая версия. Можно ли удалить вспомогательные инструменты, которые были установлены приложением (SMJobBless() и т. Д.), Когда приложение будет удалено? Если да, то как?

Длинная версия:

Мак приложения мы развиваемся, к сожалению, требует прав администратора для выполнения случайной работы, и это также требует фоновой задачи, чтобы быть живыми для плагин других приложений для подключения к даже если приложение сам не работает (этот человек может быть непривилегирован). Приложение будет подписано с сертификатом удостоверения разработчика и распространено только за пределами App Store.

Мы хотели бы, чтобы приложение было «хорошим гражданином», насколько это возможно, также при удалении.

Для фоновой задачи мы используем элемент входа, созданный с использованием SMLoginItemSetEnabled(). Это не удивительно, потому что обмен сообщениями XPC, похоже, не работает (вместо этого мы используем CFMessagePort - альтернативные предложения приветствуются), но если пользователь удаляет приложение, элемент входа по крайней мере больше не загружается при следующем входе в систему , Я подозреваю, что в системе все еще есть след, но исполняемый файл внутри пакета .app используется, и когда это исчезает, элемент входа больше не запускается.

Для случайной операции, требующей прав администратора, у нас есть привилегированный вспомогательный инструмент, который наше приложение устанавливает с помощью SMJobBless() и которое реализует именованную службу XPC, поэтому задача закручивается по требованию, когда она получает сообщение от основного приложение. Это то, что Apple рекомендует и описывает в своем Even Better Authorization Sample.

Вспомогательный исполняемый файл копируется в /Library/PrivilegedHelperTools/ по SMJobBless(), а встроенный launchd.plist - в /Library/LaunchDaemons/. Несмотря на то, что ОС имеет информацию о том, какое приложение «владеет» помощником, оно, похоже, не удаляет его, когда пользователь удаляет приложение. В примере Apple не говорится об удалении, кроме сценария uninstall.sh, который, по-видимому, предназначен для использования только в процессе разработки. Нам не нужен этот помощник, пока приложение не работает, поэтому установка его как полномасштабного демон запуска немного переборщила, но мы также хотели бы избежать неоднократного раздражения пользователя запросом пароля. Кроме того, Apple советует против других форм запуска кода с правами администратора, чем SMJobBless() в эти дни - например, SMJobSubmit() отмечен как устаревший.

Итак, как мы очищаемся после себя?

Я нашел SMJobRemove(), но (а) когда мы назовем это в нашем случае - вы не можете запустить код на удаление пакета .app, или можете? и (b) it doesn't actually seem to clean up.

только 2 вещей, которые я могу думать, не очень удовлетворительный:

1. Своего рода деинсталлятор приложения или сценария. Но это кажется довольно уродливым.
2. Не беспокойтесь об этом и просто оставите беспорядок, когда пользователь удалит наше приложение.

Answer 1

Был такой же вопрос на форумах разработчиков Apple по адресу https://forums.developer.apple.com/thread/66821. Рекомендация Apple - это механизм ручного удаления и использование как можно меньше ресурсов, если пользователь этого не делает.

Сотрудники Apple DTS также рекомендовали внедрить механизм самообучения в привилегированном демонстрационном запуске, который запускается из приложения через XPC. Это то, с чем мы идем.

Answer 2

Я думаю, что единственным решением, которое у вас есть сейчас, является использование кода оболочки удаления, который вы упомянули, чтобы физически удалить привилегированный помощник с диска или создать для него деинсталлятор. В любом случае вам придется попросить пользователя ввести свой пароль. Это то, что делают все инсталляторы/деинсталляторы, которым нужен привилегированный доступ к системе, и по очень веской причине.Вот почему я избегаю чумы использовать привилегированных помощников, но я понимаю, что иногда вам действительно нужно. Я не думаю, что хорошо, что вы оставите такого помощника в системе пользователя, потому что он перезагрузится в следующий раз, когда пользователь запустит компьютер.

Я только что просмотрел заголовок ServiceManagement.h, и они утверждают, что SMJobRemove будет заменен API, который будет доступен через libxpc в будущем. (Иногда вам действительно нужно пойти в заголовки, чтобы получить дополнительную информацию, которую не дает вам документация.) Надеюсь, эта обещанная замена удалит ее для нас. Однако я бы опубликовал отчет об ошибке и попросил об этом.

Answer 3

Одним из решений, которое вы можете рассмотреть, является включение сценария или программы удаления в ваш пакет .app.

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