trackd

Cleanly uninstall anything — even if it didn't come from a package manager.

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, and package databases are cleaned up automatically.

Works with apt, pip, npm, make install, curl-pipe-bash scripts — anything that touches the filesystem.

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 pip installed something globally and it scattered files across your system. Or you want to try 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.

Install

From .deb (recommended — no Rust toolchain needed)

Download the latest .deb from Releases:

sudo dpkg -i trackd_0.1.0_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.0_amd64.deb

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

Quick start

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

# Track an apt package
trackd apt install cowsay

# Track a pip package
trackd pip install flask

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

# 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 <n> -- <cmd>	Run a command and track its filesystem changes
trackd apt install <pkgs>	Track an apt-get install
trackd pip install <pkgs>	Track a pip install
trackd npm install <pkgs>	Track an npm install
trackd remove <n>	Revert a tracked session
trackd remove <n> --dry-run	Preview what revert would do
trackd list	List tracked sessions
trackd show <n> --changes	Show what a session changed
trackd status	Show snapshot and session info
trackd snapshot	Retake baseline snapshot
trackd dbremove <n>	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, created files are deleted (deepest first), and for apt packages the dpkg database is cleaned up automatically.

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 <n> --changes gives a complete manifest of every file an installer touched.

When NOT to use trackd

• Docker/containers — use container layers instead.
• System packages you plan to keep — just use apt normally.
• Snap/Flatpak — they have their own sandboxing and rollback.

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), except for trackd apt install which runs apt-get as root directly.
• Backup directories are verified to be root-owned and not group/world-writable before any file is written or restored.
• Session names, package 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 (apt, dpkg, pip, npm) 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; use trackd apt install for package manager operations.
• 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. Use trackd apt install instead of trackd install foo -- sudo apt-get install foo.

License

MIT