Linux sandbox 0.162: deny_read entries that name the same file through a symlink fail with "Unable to mount source on destination: No such file or directory" #52658

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   on Oct 9, 2026
2. argszero commented on Oct 9, 2026

   

   argszero

   on Oct 9, 2026

   More actions

   Root cause confirmed on main (45311351c2) — and your #48155 pointer is right: that is the change that introduced it (645b683a9e, "Preserve filesystem denials when preparing approved commands").

   Why the alias pair exists

   get_unreadable_roots_with_cwd normalizes entries, so two spellings of one file collapse to the resolved path and /var/home/user/.codex/auth.json survives alone. get_unreadable_roots_with_cwd_preserving_symlinks then pushes the literal entry back whenever !roots.contains(&entry.path). The doc comment says why: the literal is what lets Linux reject a denial that crosses a writable symlink, instead of masking only the symlink's current target (bwrap.rs, first_writable_symlink_component_in_path). So the literal is load-bearing for the fail-closed check and redundant for masking.

   Why the second mask fails

   create_filesystem_args dedups the root list only by path string (sort() + dedup()), so the alias pair survives it. Both entries are files, so both reach append_existing_unreadable_path_args → --perms 000 --ro-bind-data <fd> <path>, once per spelling, from the rootless loop — exactly the two --ro-bind-data argument you dumped. Directories are unaffected because --tmpfs masks stack, which matches what you observed.

   Fix — your suggested rule, plus one refinement

   Branch fix/symlink-alias-file-mask-dedup, commit de942b793a (+101/−3, codex-rs/linux-sandbox/src/bwrap.rs only):

   • Each mount phase claims the resolved identity of a file before masking it (claim_file_mask_target), and an alias of an already-claimed file reuses that mask.
   • Identity comes from the longest existing ancestor, not the leaf, so a missing denied file resolves through the same identity too — and hard links keep separate identities, because masking one path does not hide the other.
   • The claim set is per mount phase rather than global. This is deliberate: binding a writable root shadows masks applied before it, so the nested loop legitimately re-masks the same path after each bind, and a global set would drop those.
   • The writable-symlink check still runs for the literal alias before it can be dropped, so the fail-closed behaviour that #48155 added is untouched: a denial that crosses a writable symlink still errors out.

   The first mask keeps hiding the file through the alias, because the symlink itself lives under the read-only root.

   Verification limits (worth stating plainly)

   bwrap is Linux-only and this crate is #[cfg(target_os = "linux")], so on my macOS host I could not run the sandbox or the test binary — a cargo check --target x86_64-unknown-linux-gnu stops in ring/aws-lc-sys for want of a Linux C cross-compiler. What I did verify: the new identity function run verbatim in a standalone harness (two spellings collapse in both orders, hard links stay separate, a missing leaf resolves through the existing ancestor, distinct files never collapse), and the file is rustfmt-clean. The regression test symlinked_deny_entries_mask_one_file_once is included, but it needs a Linux host to execute — the CI run on that target is the real gate.

   Happy to move the dedup into the policy layer instead if you would rather get_unreadable_roots_with_cwd_preserving_symlinks not hand out redundant literals; I kept it in bwrap.rs because that is where the mask list is placed into phases.