Re: Using KAuth for Monitoring File Operations
site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Jun 15, 2007, at 6:59 AM, Amanda Walker wrote: Hang a sec there, Amanda. That being said, let's try to set you on a right path. What do you define as "modified"? You have a couple of problems here; = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Jun 15, 2007, at 4:05 AM, Yogesh Kulkarni wrote: The application i am currently working on needs to do simple Copy- On-Write mechanism by which i will be able to take the backup of those files which are going to be modified. So, i am more interested in getting the event before the read/write operation on particular file or before the data gets modified for the file. But currently KAuth is giving event to my user space application after the file data gets modified because of this i am not able to get the previous state of that file for achieving Copy-On- Write mechanism. My main aim is to keep the previous state of the file to some other location before modified data gets written to that file. This is not going to be possible with Kauth, since a Kauth module gets notified after the I/O operation is already underway. You can deny the operation, but you can't interpose user space processing in between seeing the request and either denying it or letting it proceed. Firstly Yogesh, you should check with your co-workers, or perhaps whoever had this project last; I think we were last talking about this late in April with Shailesh Parulekar, and I'm sure I've answered these questions at least once before that. In the most simplistic case, you can hook the VNODE scope, and any time an operation goes past that looks like it might be requesting the right to alter a file, consider the file to be potentially about to be modified. - You have no idea whether the file will actually be modified, or whether permission will even be granted to modify the file, just because you have seen a request to be granted permission to modify go past. - The file may already be open, meaning that if you back it up and overwrite a previous version, you may end up saving a version with partial changes. If your product's aim is to have a complete backup copy of everything, then you are better off waiting in the FILEOP scope for last-close notifications with the modified flag set. This gives you both the indication that the file is not being modified, and an indication that it previously has been. All of this leaves the issue of metadata changes completely up in the air. This email sent to site_archiver@lists.apple.com
participants (1)
-
Michael Smith