Harden permissions for local history DB and tee logs

Summary

RTK stores privacy-relevant local history and raw tee output under the platform local data directory. In v0.39.0, the tracking DB and tee log paths are created with default filesystem behavior rather than explicit restrictive Unix permissions.

This is local data hardening, not an accusation of malware.

Version / tag / commit

• Tag: v0.39.0
• Commit: 2fbc7514f6964acabcfac65501b8bb6b525e3aa8

Evidence

The local files can contain sensitive local data:

• src/core/tracking.rs:263-318 creates commands(original_cmd, rtk_cmd, project_path, ...) and parse_failures(raw_command, error_message, ...).
• src/core/tracking.rs:417-426 records the canonical current project path with each command.
• src/core/tracking.rs:465-483 records raw parse-failure commands and error messages.
• src/core/tee.rs:105-146 writes raw command output to tee .log files.

Tracking DB and tee logs do not set explicit restrictive permissions in the reviewed source:

• src/core/tracking.rs:249-255 creates the parent directory with std::fs::create_dir_all and opens the SQLite DB with Connection::open(&db_path).
• src/core/tee.rs:113-141 creates the tee directory with std::fs::create_dir_all and writes the tee file with std::fs::write.

There is an existing precedent for explicit local-data permissions:

• src/core/telemetry.rs:174-186 creates the device salt file and, on Unix, sets it to 0o600.

Duplicate search performed:

• gh issue list -R rtk-ai/rtk --search "history db tee permissions 0600"

No focused duplicate was found.

Impact

On Unix-like systems, default file modes depend on process umask and parent directory permissions. If the user's environment has permissive defaults, history.db or tee logs could be readable by other local users. The risk is local-only, but the stored fields can include command arguments, project paths, parse failure text, and raw command output.

Verification steps

1. Inspect src/core/tracking.rs:249-255 and src/core/tee.rs:113-141.
2. Compare with src/core/telemetry.rs:174-186, which explicitly sets the salt file to 0o600.
3. Confirm there is no analogous set_permissions for history.db, its WAL/SHM files, the rtk data dir, the tee dir, or tee .log files.

Suggested mitigation

On Unix:

• create the RTK data directory and tee directory with 0o700 where possible;
• set history.db, SQLite sidecar files where feasible, and tee .log files to 0o600;
• add tests behind #[cfg(unix)].

On Windows, document reliance on the user's local app-data ACLs unless explicit ACL hardening is added.