sandbox: chdir into tmpdir before exec to avoid getcwd EPERM

[jamessawle]

---

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them? Performance claims (e.g. "this is faster") must include Hyperfine benchmarks.
• Have you written new tests (excluding integration tests) for your changes? Here's an example.
• Have you successfully run brew lgtm (style, typechecking and tests) with your changes locally?

---

• AI was used to generate or assist with generating this PR.

Diagnosis and patch were produced with Claude Code. The author read the upstream source (sandbox.rb, utils/fork.rb, mktemp.rb, resource.rb), the macOS kernel log (log show … Sandbox), and the failing HOMEBREW_DEBUG=1 stack traces directly before, during, and after the change — I'm vouching for the fix on the merits, not because an LLM produced it. Earlier sessions (including one in jamessawle/osch#67) chased two wrong hypotheses (eager Pathname.pwd in Resource#unpack, and macOS TCC tightening) before kernel-log + source reading landed on this one; that history is in the issue for anyone curious about what was not the bug.

---

Summary

Since commit dd8119e ("Harden sandboxed install phases", 2026-05-27), Sandbox#deny_read_home deny-reads sensitive home subpaths (~/Documents, ~/.ssh, ~/.aws, ~/.gnupg, ~/.config/gcloud, ~/Library/Keychains, ~/Dropbox, etc.) inside the build and postinstall sandboxes.

The sandboxed child inherits the user's CWD from the parent brew invocation. When the user runs brew install <source-style-formula> from a CWD under one of those denied subpaths, the first getcwd(3) in the child — getcwd walks every parent inode calling file-read-metadata — hits the deny rule, returns EPERM, and the install crashes with:

Error: An exception occurred within a child process:
  Errno::EPERM: Operation not permitted - getcwd

The first getcwd happens to live in Resource#unpack (eager current_working_directory = Pathname.pwd at the top of the method), but removing that just defers the EPERM by one frame to Mktemp#run's block-form Dir.chdir (Ruby's block-form Dir.chdir calls getcwd internally to save the previous directory). There are likely more such call sites downstream. So this PR fixes the underlying cause rather than the first symptom: it moves the sandboxed child into a non-denied directory before exec, so every subsequent getcwd walks only /opt/homebrew/... parents.

The patch

In Sandbox#run's child branch, just before exec-ing into the sandbox profile, Dir.chdir(tmpdir) (where tmpdir is the per-invocation Dir.mktmpdir("homebrew-sandbox", HOMEBREW_TEMP) already allocated a few lines up). The non-block form of Dir.chdir does not itself call getcwd, so this works even when starting from a denied CWD — only chdir(2) runs.

What this does NOT change

• The deny rules added in dd8119e remain intact; this PR does not weaken sandbox hardening in any way.
• Bottles were never affected (they cd into HOMEBREW_CELLAR/<name>/<version> before any getcwd runs); behaviour is unchanged there.
• Resource#unpack's eager Pathname.pwd is left alone — with the CWD now under HOMEBREW_TEMP it walks only safe parents, and removing it would be a real (if usually-dead) semantic change for relative-target callers per a01715f.

Repro

Before this patch, on macOS with Homebrew including dd8119e:

cd ~/Documents/anywhere   # or ~/.ssh, ~/.aws, etc.
brew install --build-from-source <any-source-style-formula>
# Error: An exception occurred within a child process:
#   Errno::EPERM: Operation not permitted - getcwd

Kernel log during the failure:

kernel: (Sandbox) Sandbox: ruby(PID) deny(1) file-read-metadata /Users/<u>/Documents

Stack trace (with HOMEBREW_DEBUG=1), showing both candidate first-getcwd sites depending on which one you fix:

Errno::EPERM: Operation not permitted - getcwd
  Library/Homebrew/resource.rb:142:in 'Pathname.getwd'        # original
  Library/Homebrew/resource.rb:142:in 'Resource#unpack'
  …

Errno::EPERM: Operation not permitted - getcwd
  Library/Homebrew/mktemp.rb:97:in 'Dir.chdir'                # after fixing resource.rb only
  Library/Homebrew/mktemp.rb:97:in 'Mktemp#run'
  Library/Homebrew/resource.rb:286:in 'Resource#stage_resource'
  …

Verification

Tested locally on macOS 26.5 arm64, Homebrew 5.1.14-41-g0cba9a2:

Scenario	Before patch	After patch
cd ~/Documents/foo && brew reinstall jamessawle/tap/osch (source-style)	EPERM crash	succeeds
cd ~ && brew reinstall jamessawle/tap/osch (source-style)	succeeds	succeeds
cd ~/Documents/foo && brew reinstall jq (bottle)	succeeds	succeeds
brew tests --only=sandbox	passes	passes
brew tests --only=resource	passes	passes
brew lgtm (typecheck + style + changed tests)	n/a	passes

Tests

Added sandbox_spec.rb regression: stand up a fresh Sandbox, deny_read_path a tmpdir, Dir.chdir into it, and run /bin/pwd through the sandbox. Without the patch this raises ErrorDuringExecution (sandbox-exec exits 1 from getcwd EPERM); with the patch it succeeds. Verified both directions locally by stashing/unstashing the sandbox.rb change.

Links

• Precipitating commit: dd8119e
• Downstream diagnosis (kernel log + traces, not required reading): brew install/upgrade fails with 'getcwd EPERM' from ~/Documents on macOS Tahoe (upstream Homebrew bug) jamessawle/osch#67

[MikeMcQuaid]

Thanks!