[gold-silver-copper]

fix(harness): keep prompt history and run logs private to the user

Description

Prompt history (projects/<project>/tui/history.jsonl) and the logs of failed runs (under run/) were created with ordinary modes in ordinary directories, so on a shared machine another local user could read them. #3137 tightened only sessions/. This widens the same best-effort rule to the four directories that hold what the user said, and leaves the rest of RIG_HOME alone.

What users see change

On unix:

• sessions/, projects/, data/ and run/ under RIG_HOME are mode 0700 once rig has started, on a fresh home and on an existing home whose directories were 0755.
• Once these directories are 0700, another local user can't open prompt history or the logs of failed runs inside them. On an old home that starts at the next rig start, and a process that already has one of those files open keeps it.
• A symlink at one of those four paths to a directory elsewhere is followed, and that directory is made 0700, as sessions/ already was.
• A regular file at one of those paths, or a symlink there that leads back to RIG_HOME itself, is left as it was.
• RIG_HOME's own mode does not change, and neither do the modes of files. Other entries under RIG_HOME, such as bin/ and settings.toml, keep their modes.
• Best effort: a directory whose owner or filesystem refuses the change keeps its mode and rig carries on.
• A home that cannot hold a new session or a run directory still fails with an error, as before.
• A build describing itself still creates nothing.

Windows and wasm: nothing changes.

Public API

One additive method on rig_harness_protocol::Home. Nothing else in the public API changes.

Before: no such method. The chmod of sessions/ was written out in Home::new_session and again in paths_in.

After:

impl Home {
    /// On unix, creates `sessions/`, `projects/`, `data/` and `run/` and
    /// makes them this user's alone. Best effort. Elsewhere it does nothing.
    pub fn keep_private(&self);
}

home.keep_private();

It is called from Home::new_session, paths_in (still guarded by describing()) and the launcher's hold_run, before anything is written under those directories.

Changelog

• (harness) On unix, sessions/, projects/, data/ and run/ under RIG_HOME are made private to the user (0700, best effort), so another local user cannot read prompt history or failed-run logs. Adds Home::keep_private.

Migration

None.

Type of change

• Bug fix
• New feature
• Breaking change
• Documentation update

Testing

• keep_private_tightens_the_four_directories_and_not_the_home in rig-harness-protocol: covers an existing 0755 directory, a directory that was absent (created private), and a link to a 0755 directory elsewhere, each ending with no group or other bits. A second home has projects linked to the home and a regular 0644 file at data. Both homes stay 0755 and the file stays 0644. On the test commit it cannot compile, because the method is new. It passes on the head, and it fails with the directory and home check removed (the linked home and the file both become 0700).
• cargo xtask verify --affected --base origin/main at this head on the build server: all 10 checks passed.

PR	Verdict	Test
none (audit finding e-3)	confirmed in the code; fixed	keep_private_tightens_the_four_directories_and_not_the_home

Line deltas: production +19 / -8, tests +45 / -0. No existing test was changed.

Checklist:

• I have updated READMEs and Rust docs affected by this change
• I have added tests that prove my fix is effective or that my feature works
• I did not edit CHANGELOG.md or MIGRATING.md (they are generated at release)

Notes

Not verified by the author: the change has not been driven in the real app, and the three call sites have no test of their own, so real-use testing covers them. No non-unix build was run locally. On those targets the cfg(unix) loop drops out and keep_private is empty.

The loop is entirely cfg(unix), including its create_dir_all, so Windows does not gain three empty directories. paths_in keeps its own create_dir_all(sessions) for that reason.

Follow-ups, not in this PR:

• A new top-level directory that holds user text has to be added to keep_private's list by hand.

Choices left to the owner: none.