1

观察到在文件修改或文件复制期间，FWRITE 或 KAUTH_FILEOP_CLOSE_MODIFIED 在动作 KAUTH_FILEOP_CLOSE 中的设置不一致。

我的用例是 - 我试图弄清楚正在关闭的文件是修改后的文件还是新创建的文件。我想忽略未修改的文件。

根据文档，当文件操作为 KAUTH_FILEOP_CLOSE 时，我正在检查 KAUTH_FILEOP_CLOSE_MODIFIED 标志。大多数时候，我观察到当文件从一个位置复制到另一个位置或文件被修改时，未设置 KAUTH_FILEOP_CLOSE_MODIFIED。

我还观察到设置了 FWRITE 标志，但对于修改或复制的文件并不一致。我只是想知道为什么行为如此不一致。

我在想的另一种方法是依赖 vnode 操作 KAUTH_VNODE_WRITE_DATA，但我观察到在 KAUTH_FILEOP_CLOSE 之后甚至没有修改文件时也有多次调用 KAUTH_VNODE_WRITE_DATA。

知道为什么存在这种行为吗？

提前致谢。

问候，

鲁佩什

4

1 回答 1

3

KAuth 尤其KAUTH_FILEOP_CLOSE_MODIFIED是错误的，我已经向 Apple 报告了一些与它相关的问题（很久以前）：

也就是说，我非常有信心（从 10.5.x、10.6.x、10.7.x 开始）回调总是直接从执行系统调用的内核线程调用。例如，当open(2)被调用时，它会调用 vnode 上下文的 kauth 回调，然后（如果返回值允许）调用 VFS 驱动程序来实现操作。fileop ( KAUTH_FILEOP_CLOSE) 也可以在同一个线程中工作，但只是在关闭本身之后调用。

因此，我认为KAUTH_VNODE_WRITE_DATA不能参加KAUTH_FILEOP_CLOSE同一活动。

您的代码中存在错误，或者它是另一个事件（例如，在同一个或其他进程中关闭同一个文件后下一次打开该文件。）

仍然有一些你必须注意的陷阱：

  • 内核本身（包括其他 kexts）执行的任何 I/O 都不会触发 kauth 回调。
  • 如果 vnode 上下文有多个回调（例如，来自多个 Kext），内核会为每个事件一个接一个地调用它们。然而，一旦它们中的一些返回KAUTH_RESULT_ALLOWor KAUTH_RESULT_DENY，它最终决定并且不会调用其余的回调。即所有回调仅在除最后一个 return 之外的所有回调时被调用KAUTH_RESULT_DEFER。（AFAIK，对于 fileop，这是不正确的，因为在这种情况下，返回值被完全忽略。）
于 2012-06-08T14:44:45.047 回答