Without getting into the details of why, I\'m looking for a clean (as possible) way to replace kernel functions and system calls from a loadable module. My initial
If the shared libraries call a system call, you are going ot make a module that alters that sysltem call. For more information on altering system calls, you might want to look here http://www.xml.com/ldd/chapter/book/ there is something in there in how they change what the open() system calls. An example is here http://tldp.org/LDP/lkmpg/x931.html
You don't want to modify existing system calls, you want to instrument them. This is what SystemTap is for. If you really want to do it the hard way and intercept system calls by coding your own module, I suggest you read some rootkit literature but I don't have any link handy (although phrack comes to mind).
I think you can use audit for that
have a look at http://www.tldp.org/LDP/lkmpg/2.6/html/x978.html
Have you looked at deploying your function using LD_PRELOAD?
Your function would be deployed via a shared lib that would live in a directory that is specified by the environment variable LD_PRELOAD.
The convention is that you intercept system calls and then, after performing your magic, pass the call onto the actual system shlib. But you don't have to do that.
Maybe take a look at the article "Building library interposers for fun and profit". While it is Solaris specific, it is also applicable to Linux.
BTW This is how most memory analysis tools, e.g. Purify, work.
There has been a lot of work done in the kernel to make sure this does not happen, especially work to not expose the syscall table to modules. The only supported mechanism to log file access is LSM, but it is oriented towards security and has an uncertain future. Here is a PDF that documents the API, but it may not be up to date.
inotify is a much better way to monitor the creation, deletion and modification of files than trying to subvert the kernel syscall functions, but it works from userspace.
Quoted from Wikipedia (http://en.wikipedia.org/wiki/Inotify): Some of the events that can be monitored for are:
* IN_ACCESS - read of the file
* IN_MODIFY - last modification
* IN_ATTRIB - attributes of file change
* IN_OPEN and IN_CLOSE - open or close of file
* IN_MOVED_FROM and IN_MOVED_TO - when the file is moved or renamed
* IN_DELETE - a file/directory deleted
* IN_CREATE - a file/directory created
* IN_DELETE_SELF - file monitored is deleted
inotify exists in the kernel since 2.6.13, its predecesor is dnotify (http://en.wikipedia.org/wiki/Dnotify).