modetc: A Linux Kernel Module for Rewriting File Paths to Relocate Stubborn Dotfiles

The Linux ecosystem has long struggled with applications that stubbornly place configuration files in the home directory, ignoring the XDG Base Directory Specification that would move them to more appropriate locations like ~/.config or ~/.local/share. For users who prefer a clean home directory and standardized file organization, this creates a persistent friction point. A new project called modetc proposes an unconventional solution: rewrite file paths at the kernel level.

The Nuclear Option for Dotfile Management

modetc is a Linux kernel module that intercepts file operations and rewrites paths in real-time. The core idea is simple yet radical: instead of trying to convince each application to change its behavior, modetc intercepts system calls and modifies the file paths before the kernel processes them. This allows users to move files anywhere they want while programs continue to find them in their expected locations.

For example, you could configure modetc to rewrite all references to ~/.ssh to ~/var/lib/ssh, effectively moving SSH configuration out of the home directory while maintaining compatibility with SSH clients that expect the traditional location.

How It Works: Kernel-Level Path Rewriting

modetc operates by inserting kprobes into key functions within the Linux kernel's Virtual File System (VFS) layer and system call implementations. Kprobes are a debugging and performance analysis mechanism that allows inserting breakpoints at arbitrary locations in kernel code. modetc uses them to intercept file operations like do_symlinkat, do_rmdir, and other path-handling functions.

When any of these functions is called, the kprobe triggers and executes a small piece of code that modifies the file path argument in-place. The modification happens in the kernel's names cache (names_cachep), which contains the kernel-space copy of user-space file paths. This means the process that initiated the system call remains completely unaware of the path modification.

The rewriting rules are configured through a simple text file (/etc/modetc.conf) containing search-and-replace patterns. Rules are applied in order, with the first matching rule taking precedence. If no specific rule matches, a default replacement is applied. The maximum number of rules is currently limited to 16.

Configuration and Usage

Configuration is handled through module parameters set either when loading the module manually or via /etc/modprobe.conf. Key parameters include:

• homedir: The home directory where path rewriting should apply
• default_rule: The default replacement for unmatched dotfiles
• rules_file: Path to the rules configuration file
• debug: Enable debugging output

Runtime control is available through /proc/modetc, allowing users to pause rewriting, reload rules, or query status without unloading the module.

Building and Installation

The project provides Nix expressions for building and testing. Users can build the module with nix-build -A module and test it in a virtual machine with nix-build -A test before deploying to their system.

For NixOS users, installation involves adding the module to the system configuration, specifying the kernel version, and configuring the rewriting rules. The project includes a complete NixOS configuration example that handles module loading and parameter configuration.

For other distributions, the traditional make && make install approach works, though users may need to adjust the kernel version in the build configuration.

Comparison with Alternatives

modetc enters a space with existing solutions, each with distinct trade-offs:

libetc used the LD_PRELOAD mechanism to intercept libc wrapper functions. While simpler, it fails for statically linked programs, programs that bypass libc for system calls, and requires restarting applications to change configuration.

rewritefs operates at the filesystem level using FUSE, which solves many of libetc's limitations but introduces significant performance overhead for I/O operations in the home directory.

modetc aims to provide the best of both worlds: it works for all programs (including statically linked ones), requires no filesystem mounting, runs with minimal overhead in kernel space, and allows quick toggling without restarting applications. The main limitation is that it only supports simple text substitution, not regular expressions.

Technical Trade-offs and Considerations

Using a kernel module for application-level configuration management represents a significant escalation in complexity and risk. Kernel modules run with the highest privileges and any bug can potentially crash the system or create security vulnerabilities. The modetc README explicitly notes this is "the nuclear option," and recommends testing in a virtual machine before deployment.

The project's approach also raises questions about maintainability. Kernel APIs and internal structures change between versions, potentially requiring updates to the module with each kernel release. The project acknowledges this by noting that users may need to adjust the linux argument in the Nix expression to match their kernel version.

From a security perspective, modifying file paths at the kernel level could potentially interfere with security mechanisms that rely on path verification, though the project's design (only modifying the kernel's cache) may limit this risk.

Project Status and Availability

modetc is available on the Maxwell git server under the username rnhmjoj. The current version is 0.1.3, indicating it's still in early development. The project is licensed under the GNU General Public License v3.0.

The codebase is primarily written in C (57.7%), with Nix expressions (40.9%) for build configuration and a small Makefile (1.4%). This suggests the project is focused on Linux kernel development while providing reproducible builds through Nix.

The Broader Context

modetc represents an interesting intersection of systems programming and user experience design. It acknowledges that while the XDG Base Directory Specification provides a cleaner, more organized approach to file management, adoption remains inconsistent across the software ecosystem. Rather than waiting for universal compliance, modetc offers a technical workaround that lets users enforce their preferred organization at the system level.

This approach reflects a broader pattern in the Linux ecosystem: when user-facing applications resist standardization, sometimes the solution lies deeper in the stack. Similar patterns can be seen in projects like bwrap for sandboxing or systemd for service management, where kernel or system-level features are leveraged to impose order on chaotic user-space behavior.

For developers and system administrators considering modetc, the decision involves weighing the benefits of a clean home directory against the risks and complexity of running a custom kernel module. The project's recommendation to test thoroughly in virtual environments suggests the developers are aware of these trade-offs and are approaching the problem with appropriate caution.

The project's existence also highlights an ongoing tension in the Linux desktop ecosystem: the balance between backward compatibility and modern standards. While XDG directories represent a more logical organization, decades of software have been written expecting dotfiles in the home directory. modetc doesn't resolve this tension but provides a technical bridge for users who want to adopt modern standards without waiting for universal software compliance.

As the project evolves, key questions will be whether the performance overhead remains minimal, whether the limited rule set (16 rules) proves sufficient for real-world use, and whether the kernel module approach gains broader acceptance among Linux users who prioritize system organization over simplicity.

For those interested in exploring modetc, the project is available at rnhmjoj/modetc on Maxwell git server, with full source code, build instructions, and configuration examples. The README provides detailed guidance on building, testing, and deploying the module, though users should approach this "nuclear option" with appropriate caution and thorough testing in non-production environments first.