c++ - 内核授权文件操作范围在 Mavericks 中被破坏

Question

我开发了一个系统，该系统需要使用 kext 监视文件，该 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 的安装程序，它使用关联的“runner”帮助应用程序。

当文件范围报告“runner”的执行时，文件路径是正确的，但报告的 pid 和 ppid 是父应用程序 Installer 的，而不是辅助应用程序的。

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

如Apple文档中所述，文件操作范围可用于实现反病毒扫描程序。

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

谁能告诉我在 Mavericks 中注册文件操作范围时如何检索助手应用程序的正确 pid 和 ppid？

Answer 1

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

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

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

解决方案是改用 VNode 作用域。