Hooking fopen() function throws Segmentation fault - c

Question

I'm trying to log access to a particular directory by hooking the fopen() function and using LD_PRELOAD.
My first question is: Is hooking fopen() enough to log operations that open a file?
My code throws Segmentation fault. In particular, the code is like this (ignoring error checks):
FILE* (my_fopen)(const char filename, const char* mode);
void* libc_handle;
void __attribute__ ((constructor)) init(void){
libc_handle = dlopen("libc.so.6", RTLD_LAZY);
*(void**)(&my_fopen) = dlsym(libc_handle,"fopen");
}
FILE* fopen(const char* filename, const char* mode){
printf("Hello world\n");
return my_fopen(filename, mode);
}
After compiling and specifying the new library in LD_PRELOAD, I ran
ls
and it throws Segmenation Fault. Any idea why that happened? I even tried to remove the printf(), but did not help.

Answer 1

You have some issues in your code, which are fixed in the sample below (I've also added the relevant headers and provided a main to give a complete program):
#include <stdio.h>
#include <dlfcn.h>
FILE* (*my_fopen)(const char *filename, const char* mode);
void* libc_handle;
void __attribute__ ((constructor)) init(void){
libc_handle = dlopen("libc.so.6", RTLD_LAZY);
my_fopen = dlsym(libc_handle,"fopen");
}
FILE* fopen(const char* filename, const char* mode){
printf("Hello, Pax\n");
return my_fopen(filename, mode);
}
int main (void) {
FILE *fout = fopen ("xyzzy.txt","w");
fclose (fout);
return 0;
}
The changes from what you provided are as follows:
The my_fopen function pointer should be exactly that, a pointer. I suspect you may have thought the FILE* made it so but that's not actually correct. To specify a ffunction pointer returning a FILE pointer, you need FILE * (*fn)(blah, blah).
Similarly, the first argument of that function must be a const char *, a pointer in other words. You had it as simply const char.
You don't actually need that convoluted expression for setting the my_fopen pointer (casting, taking address of, de-referencing). You can just use the much simpler my_fopen = .... In fact, I think the casting may be actually what's preventing gcc from reporting an error in this case since it's assuming, if you cast, that you know what you're doing.
You probably should also check the return value of dlopen. I haven't done that in this code but, if you don't find (or can't load) the library for some reason, the line after that will probably cause you grief.
When I compile and run this program on Red Hat Enterprise Linux Workstation release 6.4 (Santiago), I get the output of Hello, Pax and the file xyzzy.txt is created.
And, just as an aside, there are other functions which may be used to gain access to the file-system, things like open, opendir, freopen, creat, mkfifo (I think).
Depending on your needs, you may have some extra work to do.
One thing you may want to consider is that ls may not even use fopen. It can actually be built with just opendir/readdir and stat.
So, let's use a program that we know calls fopen. Enter the following program qqtest.c:
#include <stdio.h>
int main (void) {
FILE *fh = fopen ("xyzzy.txt", "w");
fclose (fh);
return 0;
}
and compile it with gcc -o qqtest qqtest.c, then run it. You should see no output but the file xyzzy.txt should be created. Once you've confirmed that, delete the xyzzy.txt file, then enter the following program qq.c:
#include <stdio.h>
#include <dlfcn.h>
FILE* (*my_fopen)(const char *filename, const char* mode);
void* libc_handle;
void __attribute__ ((constructor)) init(void){
libc_handle = dlopen("libc.so.6", RTLD_LAZY);
my_fopen = dlsym(libc_handle,"fopen");
}
FILE* fopen(const char* filename, const char* mode){
printf("Hello, Pax\n");
return my_fopen(filename, mode);
}
Compile this with gcc -shared -o qq.so qq.c -ldl and then run your qqtest program (changing the shared object path to your own directory of course):
LD_PRELOAD=/home/pax/qq.so ./qqtest
This time, you should see the Hello, Pax string output before the xyzzy.txt file is created, proof that it's calling your wrapper function, which in turn calls the original fopen.
Now, that's all very well but, even once you get this bit working, you have to intercept quite a few different calls to ensure you catch all changes.
That's going to take you quite a while to get done and, as Chris Stratton points out in a comment, the Linux kernel already has the capability to report file-system changes to you.
If your goal is to just track file-system changes rather than educate yourself on how it could be done, look into inotify to see how to do this without having to re-invent the wheel.