. Я разработал систему, которая требует мониторинга файлов с помощью kext, который регистрирует область действия файла (KAUTH_SCOPE_FILEOP). В OSX 10.8 и старше все работает так, как ожидалось, и выполнение программ обеспечило бы требуемое pid, ppid и имя файла программы, которая начиналась с выполнения.Операция с файлом авторизации ядра. Область действия в Mavericks.
В рамках vnode, я получить ИОК в обратный вызов, как это рекомендовано в книге 'Mac OS X Internals', следующим образом: -
data.pid = vfs_context_pid((vfs_context_t)arg0);
Для области файла я использую: -
proc_t self = proc_self();
data.pid = proc_pid(self);
proc_rele(self);
Проблема, которую я вижу в Mavericks, возникает, когда приложение запускает вспомогательное приложение через xpc. Например, установка пакета (.pkg) запускает установщик Apple, который использует ассоциированное вспомогательное приложение «runner».
Когда файловый архив сообщает о выполнении «runner», путь к файлу правильный, но сообщается о pid и ppid, это о родительском приложении, Installer, а не о вспомогательном приложении.
При тестировании регистрация в области VNode (KAUTH_SCOPE_VNODE) сообщает о правильном pid и ppid.
Как указано в документации Apple, область действия файла может использоваться для реализации программы антивирусной проверки.
В этой ситуации, если pid и ppid вспомогательного приложения сообщаются как приложение своего родителя, вспомогательное приложение может быть незамечено.
Может ли кто-нибудь сказать мне, как получить правильный pid и ppid вспомогательных приложений при регистрации в области операций с файлами в Mavericks?
Вы уверены, что вспомогательные приложения фактически не выполняются в рамках одного процесса? Когда я играл с KAUTH_SCOPE_FILEOP, я бы увидел процесс fork, а затем выполнил другой процесс (таким образом, я бы получил два уведомления). Также обратите внимание, что при загрузке, чтобы получить PID таким образом, вы должны использовать область VNODE, поэтому вопрос не имеет никакого смысла в качестве поставленного (вы не можете получить PID таким образом из слушателя KAUTH_SCOPE_FILEOP). В любом случае, вы уверены, что это не просто показывает вам вилки? – DanZimm
@DanZimm, спасибо, что указал на вопрос в моем вопросе (теперь обновлен). Вы правы, что для файлового устройства требуется другой метод для извлечения pid. Даже если развивается вилка, у дочернего процесса наверняка будет новый pid? Файлограф сообщает имя дочернего элемента родительскому pid, где область vnode правильно показывает новый pid. – TheDarkKnight