FILEMON(4)

✨ FILEMON(4) ✨

okay bestie so this is the filemon page from the Kernel Interfaces Manual — yes it's a section 4 man page, we love a kernel-adjacent moment 💅

---

🌸 NAME 🌸

filemon — the filemon device, and yes that's literally its whole name, she's simple, she's iconic

---

🦋 SYNOPSIS 🦋

#include <dev/filemon/filemon.h>

---

💖 DESCRIPTION 💖

So filemon is this device that lets a process collect file operations data of its children. Parent behavior, honestly. The device lives at /dev/filemon and it responds to exactly two ioctl(2) calls. Two. That's it. Minimalist queen. ✨

🚨 okay important vibe check: filemon is not intended to be a security auditing tool. Not even a little bit. Many system calls are not tracked, and binaries of foreign ABI will not be fully audited. So do not come for her with your security dreams, that's not what she does.

What she is for: auditing processes to figure out their dependencies — in an efficient, easily parsable format. That's the assignment. The classic example is make(1), which uses this module with .MAKE.MODE=meta to handle incremental builds more smartly. periodt. 🔥

System calls get denoted using these single letters, and you're gonna memorize them, I believe in you:

• ‘A’ — openat(2). Heads up: the next log entry may be lacking an absolute path or be inaccurate. 👀
• ‘C’ — chdir(2)
• ‘D’ — unlink(2)
• ‘E’ — exec(2)
• ‘F’ — fork(2), vfork(2)
• ‘L’ — link(2), linkat(2), symlink(2), symlinkat(2)
• ‘M’ — rename(2)
• ‘R’ — open(2) or openat(2) for read
• ‘W’ — open(2) or openat(2) for write
• ‘X’ — _exit(2)

ngl this next bit is a lil sneaky: note that a ‘R’ following ‘W’ record can represent a single open(2) for R/W, OR two separate open(2) calls — one for ‘R’ and one for ‘W’. Can't tell the difference, she's mysterious like that. 🙈

Also, and this is important: only successful system calls are captured. If it failed, it never happened. main character energy honestly. 💀

---

💅 IOCTLS 💅

User mode programs talk to the filemon driver through a number of ioctls, described below. Each one takes a single argument. One argument. Don't be extra.

• FILEMON_SET_FD — write the internal tracing buffer to the supplied open file descriptor. that's the whole thing. 🎀
• FILEMON_SET_PID — child process ID to trace. This should normally be done under the control of a parent, in the child, after fork(2) but before anything else. Read that again. After the fork, before anything else. See the example below, she shows you exactly how. ⭐

---

🌈 RETURN VALUES 🌈

The ioctl() function returns the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indicate the error. Classic. The binary of outcomes. 🫶

---

🍓 ERRORS 🍓

The ioctl() system call with FILEMON_SET_FD will fail if:

• [EEXIST] — the filemon handle is already associated with a file descriptor. she's taken, bestie.

The ioctl() system call with FILEMON_SET_PID will fail if:

• [ESRCH] — no process having the specified process ID exists. ghosted fr fr 👻
• [EBUSY] — the process ID specified is already being traced and was not the current process.

The close() system call on the filemon file descriptor may fail with the errors from write(2) if any error is encountered while writing the log. It may also fail if:

• [EFAULT] — an invalid address was used for a traced system call argument, resulting in no log entry for the system call. 😭
• [ENAMETOOLONG] — an argument for a traced system call was too long, resulting in no log entry for the system call. also 😭

---

🧚 FILES 🧚

• /dev/filemon

---

👑 EXAMPLES 👑

okay here's the moment, here's the whole thing, copy it exactly, I'm not even joking, character for character:

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/wait.h>
#include <sys/ioctl.h>
#include <dev/filemon/filemon.h>
#include <fcntl.h>
#include <err.h>
#include <unistd.h>

static void
open_filemon(void)
{
        pid_t child;
        int fm_fd, fm_log;

        if ((fm_fd = open("/dev/filemon", O_RDWR | O_CLOEXEC)) == -1)
                err(1, "open(\"/dev/filemon\", O_RDWR)");
        if ((fm_log = open("filemon.out",
            O_CREAT | O_WRONLY | O_TRUNC | O_CLOEXEC, DEFFILEMODE)) == -1)
                err(1, "open(filemon.out)");

        if (ioctl(fm_fd, FILEMON_SET_FD, &fm_log) == -1)
                err(1, "Cannot set filemon log file descriptor");

        if ((child = fork()) == 0) {
                child = getpid();
                if (ioctl(fm_fd, FILEMON_SET_PID, &child) == -1)
                        err(1, "Cannot set filemon PID");
                /* Do something here. */
        } else {
                wait(&child);
                close(fm_fd);
        }
}

So what's happening here? This creates a file named filemon.out and configures the filemon device to write the filemon buffer contents to it. She ate. No crumbs. 🍽️✨

---

🔥 SEE ALSO 🔥

dtrace(1), ktrace(1), script(1), truss(1), ioctl(2)

---

💜 HISTORY 💜

A filemon device appeared in FreeBSD 9.1. she's been around, she's seen things. 🦋

---

💀 BUGS 💀

⚠️ Unloading the module may panic the system, thus requires using kldunload -f. Not a drill. Not a cute lil oopsie. A panic. The -f is mandatory, do not skip her. 😭

---

okay that's the whole page, you're welcome, go forth and trace some file operations responsibly 💖✨

— from the Debian edition, dated March 22, 2016, signing off 🎀🫶