As it so happens, there is another significant interface with the kernel: the
/sys virtual filesystems. While they do not hold regular files, their contents are direct gateways to the kernel: to act on them is to act directly on kernel-allocated memory. For instance, if you want to drop all memory caches, you may use...
echo 3 > /proc/sys/vm/drop_caches
... and the kernel will react immediately.
Now, a program will need system calls in order to interact with the filesystem :
write, and so on... However, there is still a way to track all these system calls : the kernel provides a tracing mechanism under
/sys/kernel/debug/tracing. More specifically, tracing of system calls is handled by
/sys/kernel/debug/tracing/events/syscalls. This virtual directory contains two subdirectories for each system call. For instance, with the open system call, we have:
In these directories, you'll find a file called
enable. If it contains "1", then the associated event (entering or exiting an
open call) is being traced. I usually use the
enter event, but you may choose whatever fits your needs more.
Once you've activated the system call trace, you'll find the log at
/sys/kernel/debug/tracing/trace. Now, keep in mind that the open system call is used a lot. It is the final gateway between a program and a file, and files can be literraly anything on a Linux system. Also keep in mind that...
UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things. — Doug Gwyn
While you may monitor what happens on your system, the kernel won't try hard preventing users from doing stupid things: that's more part of the sysadmin's work.
Managing the tracing mechanism requires permissions under
/sys/kernel/debug/tracing/trace. You'll probably need to be root in order to activate and manipulate the trace. Don't forget to disable the trace when you're done.