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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |