1

Observed that FWRITE or KAUTH_FILEOP_CLOSE_MODIFIED is not consistenly set in action KAUTH_FILEOP_CLOSE during file modification or file copy.

My usecase is - I am trying to figure out whether the file being closed is modified file or newly created file. I want to ignore files that are not modified.

As per documentation, I am checking for KAUTH_FILEOP_CLOSE_MODIFIED flag when the file action is KAUTH_FILEOP_CLOSE. Most of the time, I have observed KAUTH_FILEOP_CLOSE_MODIFIED is not set when file is copied from one location to other or file is modified.

I also observed that FWRITE flag is set, but not consistently for modified or copied files. I am just wondering why the behavior is so inconsistent.

Another way I was thinking was to rely on vnode actions KAUTH_VNODE_WRITE_DATA, But I have observed that there KAUTH_VNODE_WRITE_DATA multiple calls comes after KAUTH_FILEOP_CLOSE and even when file is not modified.

Any idea why such behavior exist?

Thanks in advance.

Regards,

Rupesh

RHK
  • 131
  • 1
  • 4

1 Answers1

3

KAuth and especially KAUTH_FILEOP_CLOSE_MODIFIED is buggy, and I already reported some problems related to it to Apple (a long time ago):

  • Events happening on file descriptor inherited from parent process seem to not trigger call to the KAuth callback at all. (See http://www.openradar.me/8898118)

  • The flag KAUTH_FILEOP_CLOSE_MODIFIED is not specified when the given file has transparent zlib compression enabled. (See http://www.openradar.me/23029109)

That said, I am quite confident that (as of 10.5.x, 10.6.x, 10.7.x) the callbacks are always called directly from the kernel thread doing the syscall. For example when open(2) is called, it calls the kauth callbacks for the vnode context and then (if allowed by return value) calls the VFS driver to realize the operation. The fileop (KAUTH_FILEOP_CLOSE) works also from the same thread but is just called after the closing itself.

Hence I don't think KAUTH_VNODE_WRITE_DATA can come after KAUTH_FILEOP_CLOSE for the same event.

Either you have a bug in your code, or it is another event (e.g. next open of the same file after it was closed in the same or other process.)

Still there are some traps you must be aware of:

  • Any I/O which is performed by kernel itself (including other kexts) does not trigger the kauth callbacks at all.
  • If there are multiple callbacks for the vnode context (e.g. from multiple Kexts), kernel then calls them one by one for every event. However as soon as some of them returns KAUTH_RESULT_ALLOW or KAUTH_RESULT_DENY, it finally decides and the rest of the callbacks is not called. I.e. all callbacks are called only if all of them but the last return KAUTH_RESULT_DEFER. (AFAIK, for fileop this is not true, because in this case the return value is completely ignored.)
mity
  • 2,299
  • 17
  • 20
  • Thanks for your comments! I have observed that KAUTH_VNODE_WRITE_DATA called even when file is opened and closed without any modification. As you mentioned KAUTH_FILEOP_CLOSE_MODIFIED is buggy. So is there any other way I could identify if file being closed is actually modified or newly created. – RHK Jun 08 '12 at 18:38
  • @mity, perhaps do you know if the issue in fileop scope has been fixed. I'm currently using the KAUTH_FILEOP_CLOSE_MODIFIED bit, and it's working fine in simple cases, but I wonder if it's bullet proof. have they answered your bug report ? thanks –  Jun 27 '17 at 12:19
  • @osxUser: To be honest, I stopped tracking status of the bugs after years of inactivity from Apple side. I also do not work on product affected with the bugs anymore. But feel free to try it yourself. I disclosed the bug reports on openradar.me: See http://www.openradar.me/8898118 and http://www.openradar.me/23029109 – mity Jun 28 '17 at 06:40
  • Updated the post to include some info about the bugs. – mity Jun 28 '17 at 07:11