1

FWRITEまたはKAUTH_FILEOP_CLOSE_MODIFIEDが、ファイルの変更またはファイルのコピー中にアクションKAUTH_FILEOP_CLOSEで一貫して設定されていないことが確認されました。

私のユースケースは-閉じているファイルが変更されたファイルなのか、新しく作成されたファイルなのかを把握しようとしています。変更されていないファイルを無視したい。

ドキュメントによると、ファイルアクションがKAUTH_FILEOP_CLOSEの場合、KAUTH_FILEOP_CLOSE_MODIFIEDフラグをチェックしています。ほとんどの場合、ファイルをある場所から別の場所にコピーしたり、ファイルを変更したりすると、KAUTH_FILEOP_CLOSE_MODIFIEDが設定されないことがわかりました。

また、FWRITEフラグが設定されていることも確認しましたが、変更またはコピーされたファイルに対して一貫性がありません。なぜ動作がそれほど一貫していないのか疑問に思っています。

私が考えていたもう1つの方法は、vnodeアクションKAUTH_VNODE_WRITE_DATAに依存することでしたが、KAUTH_FILEOP_CLOSEの後で、ファイルが変更されていない場合でも、KAUTH_VNODE_WRITE_DATAの複数の呼び出しが発生することがわかりました。

なぜそのような振る舞いが存在するのか、何か考えはありますか？

前もって感謝します。

よろしく、

ルペシュ

4

1 に答える 1

3

KAuthKAUTH_FILEOP_CLOSE_MODIFIEDは特にバグが多く、これに関連するいくつかの問題を既に Apple に報告しています (ずっと前に):

  • 親プロセスから継承されたファイル記述子で発生するイベントは、KAuth コールバックへの呼び出しをまったくトリガーしないようです。( http://www.openradar.me/8898118を参照)

  • 指定されたファイルで透過的な zlib 圧縮が有効になっている場合、フラグKAUTH_FILEOP_CLOSE_MODIFIEDは指定されません。( http://www.openradar.me/23029109を参照)

そうは言っても、(10.5.x、10.6.x、10.7.x の時点で) コールバックは常に、syscall を実行しているカーネル スレッドから直接呼び出されると確信しています。たとえば、open(2)が呼び出されると、vnode コンテキストの kauth コールバックが呼び出され、(戻り値で許可されている場合) VFS ドライバーが呼び出されて操作が実現されます。fileop( KAUTH_FILEOP_CLOSE) も同じスレッドから機能しますが、それ自体を閉じた後に呼び出されます。

したがって、同じイベントのKAUTH_VNODE_WRITE_DATA後に来ることはできないと思います。KAUTH_FILEOP_CLOSE

コードにバグがあるか、別のイベントです (たとえば、同じプロセスまたは他のプロセスで閉じられた後に同じファイルが次に開かれた場合)。

それでも、注意しなければならないトラップがいくつかあります。

  • カーネル自体 (他の kext を含む) によって実行される I/O は、kauth コールバックをまったくトリガーしません。
  • vnode コンテキストに複数のコールバックがある場合 (たとえば、複数の Kext から)、カーネルはイベントごとにそれらを 1 つずつ呼び出します。KAUTH_RESULT_ALLOWただし、それらのいくつかがまたはを返すとすぐにKAUTH_RESULT_DENY、最終的に決定され、残りのコールバックは呼び出されません。つまり、すべてのコールバックは、最後の return 以外のすべての場合にのみ呼び出されますKAUTH_RESULT_DEFER。（AFAIK、fileopの場合、これは当てはまりません。この場合、戻り値は完全に無視されるためです。）
于 2012-06-08T14:44:45.047 に答える