trackd

Cleanly uninstall anything your system doesn't already track.

trackd wraps any install command and records every file it creates, modifies, or deletes. When you want to undo it, trackd reverts everything: files are deleted, originals are restored from backup, renames are undone.

It's the tool for make install, curl | bash installers, vendor setup.sh scripts, anything that drops files on your filesystem with no native uninstall.

trackd install myapp -- make install    # track it
trackd remove myapp                     # undo it, completely

Why

You compiled something from source and ran make install. Now you want it gone. There's no make uninstall. You have no idea what files it put where. You're stuck.

Or you ran someone's install.sh from GitHub. Or downloaded a vendor's curl | bash installer. Or you want to try out some software without committing to it.

trackd solves this. It watches what the installer does, backs up anything it's about to modify or delete, and gives you a clean undo button.

What trackd is not for

If your distribution's package manager already tracks the install — apt, dnf, pacman, pip, npm, cargo install — just use those tools. They have their own state, their own uninstall, and their own transactional model. trackd does not wrap them; layering trackd on top would duplicate bookkeeping and produce inconsistent state if the two ever drift apart. trackd is the fallback for installs nothing else tracks, not a replacement for native package management.

Install

From .deb (recommended — no Rust toolchain needed)

Download the latest .deb from Releases:

sudo dpkg -i trackd_0.1.2_amd64.deb

This installs the binary, sets up state directories, creates a default config, and takes the initial baseline snapshot.

From source

git clone https://github.com/tyggja/trackd.git
cd trackd
cargo build --release
sudo ./install.sh

Requires Rust and a Linux x86_64 system.

Building the .deb yourself

git clone https://github.com/tyggja/trackd.git
cd trackd
./build-deb.sh
sudo dpkg -i trackd_0.1.2_amd64.deb

Requires Rust and dpkg-deb (pre-installed on Debian/Ubuntu).

Quick start

# Track a make install
trackd install myapp -- make install

# Track a shell-script installer
trackd install dotfiles -- bash setup.sh

# Track a vendor installer
trackd install vendor-tool -- ./vendor-installer.run

# See what a session changed
trackd show myapp --changes

# Preview what undo would do
trackd remove myapp --dry-run

# Actually undo it
trackd remove myapp --yes

Commands

Command	What it does
trackd install <name> -- <cmd>	Run a command and track its filesystem changes
trackd remove <name>	Revert a tracked session
trackd remove <name> --dry-run	Preview what revert would do
trackd list	List tracked sessions
trackd show <name> --changes	Show what a session changed
trackd status	Show snapshot and session info
trackd snapshot	Retake baseline snapshot
trackd dbremove <name>	Drop a session from the DB without reverting

How it works

trackd uses Linux ptrace to intercept filesystem-mutating syscalls (openat, unlinkat, renameat, etc.) before they execute. When a file is about to be modified or deleted, trackd copies it to a backup directory first. After the command finishes, all touched paths are classified against a baseline filesystem snapshot and recorded in a SQLite database.

On revert, trackd undoes everything in the correct order: renames are reversed, modified files are restored from backup, and created files are deleted (deepest first).

When to use trackd

• make install and build-from-source software. trackd's core use case. No package manager tracks these files — trackd does.
• Random install scripts. curl | bash installers, setup.sh from GitHub repos, anything where you don't know what it'll touch.
• Trying out software. Install it through trackd, evaluate it, revert if you don't want it. No leftovers.
• Auditing. trackd show <name> --changes gives a complete manifest of every file an installer touched.

When NOT to use trackd

• Anything your package manager already tracks — apt, dnf, pacman, pip, npm, cargo install, snap, flatpak. Use those tools directly.
• Docker/containers — use container layers instead.

Configuration

Edit /etc/trackd/config.toml:

# Extra paths to skip during snapshot
# skip_paths = ["/data/scratch"]

# Extra filesystem types to skip
# skip_fstypes = ["virtiofs"]

# Paths to remove from the built-in skip list
# force_include_paths = ["/var/cache"]

# Max file size for backup in MB (default 100)
# max_backup_size_mb = 100

# Max changes per session (default 100000)
# max_session_changes = 100000

# Max total backup size per session in MB (default 1000)
# max_total_backup_size_mb = 1000

File layout

Path	Purpose
/usr/local/bin/trackd	Binary (setuid root)
/etc/trackd/config.toml	Configuration
/var/lib/trackd/trackd.db	SQLite database
/var/lib/trackd/backups/	Pre-modification file backups

Security

trackd runs as a setuid root binary — it needs root to ptrace child processes and to back up/restore files across the entire filesystem. The security model:

• The traced command runs as your user — privileges are dropped before exec, regardless of how trackd was invoked (direct setuid or via sudo).
• Backup directories are verified to be root-owned and not group/world-writable before any file is written or restored.
• Session names and paths are validated to prevent injection.
• Backup files are owned by root and have setuid/setgid bits stripped.
• The config file is ignored if it's not root-owned or is world-writable.

Threat model

trackd is an audit and revert tool, not a security sandbox. Specifically:

• Tracing relies on ptrace. A multi-threaded install process can rewrite the syscall-argument buffer between trackd's read and the kernel's read, causing trackd to record the wrong path while the kernel acts on the attacker-chosen one. Single-threaded installers (most make install flows, most shell-script installers) are not affected in practice, but a deliberately hostile multi-threaded command inside trackd install can produce an incomplete change log.
• ptrace cannot follow setuid execs (the kernel marks them non-dumpable). Commands invoked through sudo inside trackd install are not traced past the sudo boundary; rerun the inner command directly without sudo, or run package managers outside trackd.
• The revert path trusts the baseline metadata trackd itself captured. A baseline taken on a compromised system will faithfully restore the compromised state.

If you need integrity guarantees against a hostile install command, run it inside a container/VM and use trackd inside that boundary.

Limitations

• Linux x86_64 only. ptrace syscall interception is architecture-specific.
• Files over 100MB are not backed up (configurable). Metadata is still recorded.
• ~10–20% overhead on traced commands from ptrace interception.
• Cannot trace through setuid binaries like sudo. If your installer needs root, run trackd as root (the setuid bit handles this) and let trackd drop to your user automatically — don't put sudo inside the traced command.

License

MIT