fix(cli): handle trusted Linux system aliases during install activation

[DavidHLP]

Summary

This draft PR addresses the install-staging failure described in #2175.

• On Linux, resolve only root-owned system aliases (/tmp, /var, and /home) during POSIX activation path walking.
• Keep rejecting arbitrary user-owned symlinks before the O_NOFOLLOW walk.
• Preserve existing macOS behavior and normal non-symlink paths.

Reproduction

On an Arch Linux host with a btrfs project filesystem, using Docker 29.7.2 and an Ubuntu Noble image built from test-infrastructure/Dockerfile, v0.10.8 failed when:

• the container's /tmp was replaced by a root-owned symlink to /tmp-real;
• the install target parent did not exist on a writable btrfs bind mount;
• the process ran as UID 1000 with a clean TMPDIR.

The observed error was:

failed to stage install candidate: activation transaction I/O failed

Root cause

cli.c stages to /tmp/cbm-install-XXXXXX when the target parent is absent. On Linux, activation_posix_walk_path() did not canonicalize trusted system aliases before secure traversal. O_NOFOLLOW therefore rejected the root-owned /tmp alias even though it is a legitimate system-managed layout.

Validation

• Patched build: successful.
• Targeted activation_transaction,cli suites: 338 passed.
• Missing target through a root-owned /tmp alias: successful.
• Existing target through a root-owned /tmp alias: successful.
• Atomic-style root-owned /home -> /var/home: successful.
• Arbitrary user-owned symlink: still rejected (non-zero, no target).
• git diff --check: passes.

Scope and review request

I did not test the exact Fedora bootc/SELinux image. I also could not reproduce the issue report's exit code 0: the controlled direct binary returned 1, and the current main propagates the handler result. Please review whether this minimal trusted-alias rule matches the project's intended Linux policy, and advise whether the exit-code discrepancy needs a separate fix.

Fixes #2175

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[DavidHLP]

Verification update

I rebuilt the patched v0.10.8 binary in the existing Ubuntu 24.04 Docker test image and reran the focused validation.

Results:

• activation_transaction,cli: 338 passed
• root-owned /tmp alias with a missing target parent: rc=0, binary installed
• existing target directory: rc=0
• Atomic-style root-owned /home -> /var/home: rc=0, binary installed
• arbitrary user-owned symlink: rc=1, target was not created

The reported direct-command exit-code discrepancy is not reproducible with this binary: the rejected user-owned-symlink case returns 1, and the current main propagates the install handler result. I am not adding an unrelated exit-code change without a reproducer.

The PR workflow still has one underlying failing job, test / test-msan; the other PR checks are green. Its log reports a daemon-bootstrap test timeout without a MemorySanitizer report, and the contributor token cannot rerun that job because GitHub requires repository admin rights. Please rerun that job when convenient.

[DavidHLP]

Follow-up for commit 581f0c7:

The alias list is now Linux-only for /home; macOS retains its previous /tmp and /var policy.

I rebuilt this new head in Docker and reran the issue matrix:

• product build: build_rc=0
• root-owned /tmp alias + missing target parent: rc=0, target created
• existing target directory: rc=0, target created
• arbitrary user-owned symlink: rc=1, target not created
• root-owned Atomic-style /home -> /var/home: rc=0, target created
• final matrix status: 0

The Linux fix remains minimal and the existing O_NOFOLLOW rejection boundary is preserved.