Project 4: File Access Auditor (opensnoop Clone)

A tool that monitors all file opens on the system, showing which processes access which files, with filtering capabilities. This is essential for security auditing, debugging, and understanding application behavior.

Quick Reference

Attribute Value
Primary Language C (libbpf)
Alternative Languages Go (cilium/ebpf), Rust (aya)
Difficulty Level 2: Intermediate
Time Estimate 1 week
Knowledge Area Filesystem Tracing / Security
Tooling libbpf
Prerequisites Project 3 completed

What You Will Build

A tool that monitors all file opens on the system, showing which processes access which files, with filtering capabilities. This is essential for security auditing, debugging, and understanding application behavior.

Why It Matters

File operations are fundamental. This project teaches you to trace the VFS layer, understand file descriptors, and filter events efficiently in kernel space.

Core Challenges

  • Tracing the right syscalls → maps to open, openat, openat2
  • Resolving file descriptors to paths → maps to fd_install, dentry walking
  • Filtering efficiently → maps to in-kernel vs userspace filtering
  • Handling flags and modes → maps to interpreting syscall arguments

Key Concepts

  • File Operations in Linux: “The Linux Programming Interface” Chapter 4 - Michael Kerrisk
  • VFS Layer: “Understanding the Linux Kernel” Chapter 12 - Bovet & Cesati
  • opensnoop Implementation: BCC opensnoop

Real-World Outcome

$ sudo ./fileaudit
PID    COMM           FD   FLAGS          PATH
1234   nginx           5   O_RDONLY       /var/www/index.html
1234   nginx           6   O_WRONLY       /var/log/nginx/access.log
5678   python          3   O_RDWR         /tmp/data.json
5678   python          4   O_CREAT|O_EXCL /tmp/lockfile
9012   sshd            5   O_RDONLY       /etc/passwd

# Filter by path pattern
$ sudo ./fileaudit --path "/etc/*"
$ sudo ./fileaudit --pid 1234 --flags "O_WRONLY|O_CREAT"

Implementation Guide

  1. Reproduce the simplest happy-path scenario.
  2. Build the smallest working version of the core feature.
  3. Add input validation and error handling.
  4. Add instrumentation/logging to confirm behavior.
  5. Refactor into clean modules with tests.

Milestones

  • Milestone 1: Minimal working program that runs end-to-end.
  • Milestone 2: Correct outputs for typical inputs.
  • Milestone 3: Robust handling of edge cases.
  • Milestone 4: Clean structure and documented usage.

Validation Checklist

  • Output matches the real-world outcome example
  • Handles invalid inputs safely
  • Provides clear errors and exit codes
  • Repeatable results across runs

References

  • Main guide: LEARN_BPF_EBPF_LINUX.md
  • “BPF Performance Tools” by Brendan Gregg