syscalltrack Tux

SourceForge Logo

Frequently Asked Questions

This page is under construction! Mail me (mulix@mulix.org) with questions.

Is syscalltrack stable?

Yes, the releases are stable. We pass each release through heavy QA and testing, including regression, stress and unit testing. We don't make a release unless it has no known bugs and no regressions. The CVS version is usually stable as well, but as always, there are no guarantees.

What does syscalltrack give me that I cannot get from strace?

Syscalltrack is system wide, and does the tracing at the kernel level, while strace is per process, and does the tracing in user space. That means that syscalltrack can answer system wide questions, such as "who is deleting my file?", which strace cannot(*). Another advantage of syscalltrack is that is supports actions ("if the process does this, fail the system call"), and that it is convenient to use. Yet another advantage of syscalltrack is that it gives you the infrastructure the develop your own filtering and response mechanisms in userspace, by giving you access to the raw parameters in a convenient format through the logging device file.

(*) Ok, you can run init and every child it forks under strace, but that makes the system practically unusable.

Why can't I match to the contents of buffers?(Or can I?)

Sure you can! Just add a rule to match on the contents of buffers (e.g. PARAMS[2] == "syscalltrack" for read(2), to match on read syscalls where the void* 'buf' argument contains the string "syscalltrack"). You can use either the '==' operator or the '=~' operator (first one matches exactly, the other one is perl's "pattern match" operator).

What is all this scary stuff about matching the compiler to the kernel's? What if I fail to do so? Will sct crash? Will the kernel crash?

sct has to be compiled with the same compiler that you used to compile the kernel. Otherwise, interesting things will happen. This is not specific to sct, every Linux kernel module that is compiled seperatly from the kernel should be compiled with the same compiler the kernel was compiled with.

Can a user set rules for sct? Can a user track system calls done by another user? What if I have some files with group writing permissions, and I want to know who touches them?

syscalltrack is system wide, and requires root permissions to be used. We want to enhance it to provide limited per user support, but that's still in the far future. For the moment, only root can set rules or have access to the data.

What kind of regexps are implemented in syscalltrack?

See "matching on the contents of buffers" above, only perl's '=~' pattern match operator. Implementing wide spread regular expression filtering in user space on the output of /dev/sct_log is on the TODO list.

What are you going to do, now that the syscall table is unexported?

Very good question. Probably write a general system call hijacking patch and propose it for inclusion in the core kernel.

Do I have to compile my own kernel in order to use syscalltrack? or can I use syscalltrack with a distribution kernel?

syscalltrack has been compiled succesfully against a redhat 7.3 2.4.18-3 kernel. Instructions on how to do this are available in COMPILING, in the syscalltrack source distribution. Compilation against other distribution kernels should be possible, but we didn't try.

Update: redhat 8 contains a controversial patch to the kernel to remove the export of sys_call_table, which means syscalltrack cannot work with it. You'll need to apply this patch (TODO: add patch) to it and recompile to get it to work.

$Id: faq.html,v 1.24 2003/02/05 22:30:56 mulix Exp $