3

我开发了一个需要使用 kext 监视文件的系统，该系统在文件操作范围 (KAUTH_SCOPE_FILEOP) 中注册。在 OSX 10.8 及更早版本中，一切都按预期工作，程序的执行将提供开始执行的程序所需的 pid、ppid 和文件名。

在 vnode 范围内，我按照“Mac OS X Internals”一书中的建议在回调中检索 pid，如下所示： -

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 的安装程序，该安装程序使用关联的“运行器”帮助应用程序。

当 filescope 报告 'runner' 执行时，文件路径是正确的，但报告的 pid 和 ppid 是父应用程序安装程序的，而不是辅助应用程序的。

测试时，向 VNode 范围注册 (KAUTH_SCOPE_VNODE) 会报告正确的 pid 和 ppid。

如苹果文档所述，文件操作范围可用于实现杀毒扫描程序。

在这种情况下，如果帮助应用程序的 pid 和 ppid 报告为其父应用程序的 pid 和 ppid，则可能无法检测到帮助应用程序。

有人可以告诉我在 Mavericks 中的文件操作范围注册时如何检索帮助应用程序的正确 pid 和 ppid 吗？

4

1 回答 1

1

问题在于 Apple 正在用 posix_spawn 替换对 fork/exec 的调用。

posix_spawn 的性质意味着在创建实际进程之前通知文件范围，这是看到父 pid 而不是子 pid 的原因。

KAuth 和文件范围早于 posix 产生，这就是它在这种情况下无效的原因。

解决方案是改用 VNode 范围。

于 2015-12-15T09:59:41.847 回答