On Wednesday 06 July 2005 19:50, Greg KH wrote: > As inotify works off of open file descriptors, yes, this is true. But, > again, if you think this is really important, then why not just work > with inotify to provide that kind of support to it?
http://marc.theaimsgroup.com/?l=linux-kernel&m=110265021327578&w=2 I think Tim was told not to dig into inotify. A lot of effort has been put into testing the code Tim has presented with review from several kernel developers (listed in the cc). They too should step up and give their opinion on this. I want to believe questions were asked about this last December when we were starting into this effort. I think the conclusion from the inotify people was for us to proceed and then when we know what we really want, we can refactor should anything be in common. > I suggest you work together with the inotify developers to hash out your > differences, as it sounds like you are duplicating a lot of the same > functionality. Maybe yes and no. Now that the fs audit code is out, I think we can spot commonality. The only common piece that I can think of is just the hook. The whole rest of it is different. I hope the inotify people comment on this to see if there is indeed something that should be refactored. > Do you have any documetation or example userspace code that shows how to > use this auditfs interface you have created? people.redhat.com/sgrubb/audit The audit package is currently distributed in Fedora Core 4. The code to use Tim's fs audit code is in the user space app, but is waiting for the kernel pieces. There is a man page for auditctl that shows all the options. (fs specific options are -wWpk ) To watch /etc/shadow, you would issue: auditctl -w /etc/shadow -p wa this will generate events for any update to the file including changes to ownership or permissions. We are interested in attribute changes as well. If you wanted to watch a file in a chroot directory, you could do this: auditctl -w /var/chroot/etc/shadow -p wa -k /var/chroot The audit events would indicate the path from the perspective of the app generating the events, but since we added the /var/chroot key, we can see that it really came from the chroot dir. Hope this helps... -Steve Grubb - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
