cask: do not follow a symlinked rmdir path - #23761
Merged
Merged
Conversation
MikeMcQuaid
approved these changes
Sep 3, 2026
MikeMcQuaid
left a comment
Member
There was a problem hiding this comment.
Thanks, one nit and then ready to self-merge!
MikeMcQuaid
enabled auto-merge
September 3, 2026 16:35
Contributor
There was a problem hiding this comment.
馃煛 Changes recommended
Pathname checks remain vulnerable to races that can redirect traversal and privileged permission changes.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Hardens cask rmdir handling against symlink redirection.
Changes:
- Skips symlinks during recursive directory removal.
- Applies no-follow permission flags to symlink paths.
- Adds utility and zap regression tests.
File summaries
| File | Description |
|---|---|
Library/Homebrew/cask/utils.rb |
Adds symlink-aware permission flags. |
Library/Homebrew/cask/artifact/abstract_uninstall.rb |
Skips symlinked directories. |
Library/Homebrew/test/cask/utils_spec.rb |
Tests permission recovery safety. |
Library/Homebrew/test/cask/artifact/zap_spec.rb |
Tests symlinked zap paths. |
Review details
- Files reviewed: 4/4 changed files
- Comments generated: 2
- Review effort level: Balanced
馃挕 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
`uninstall rmdir:` and `zap rmdir:` paths are resolved from the cask, so one can name a location a local user is able to replace with a symlink. `recursive_rmdir` then recursed through the link and removed empty directories inside its target, and the `gain_permissions_rmdir` recovery round ran `chflags`, `chmod` and `sudo chown` against the target because it passed no `-h`. - skip symlinks in `recursive_rmdir`, which also replaces an uncaught `Errno::ENOTDIR` with treating the path as not empty - always pass `-h` in `gain_permissions_rmdir`, which is a no-op on a real directory and so needs no decision from a path that could change before the recovery runs
dduugg
force-pushed
the
cask-rmdir-symlink-guard
branch
from
September 3, 2026 16:51
c97bc3a to
2abb5d2
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
uninstall rmdir:andzap rmdir:paths come from the cask, so one can name a location that a local user is able to replace with a symlink.recursive_rmdirrecursed through such a link and removed empty directories inside its target, andgain_permissions_rmdirthen ran itschflags,chmodandsudo chownrecovery round against the target too, because it passed no-h. The uninstall aborted afterwards with an uncaughtErrno::ENOTDIR, so that path never removed anything successfully anyway.Skipping symlinks in
recursive_rmdirand always passing-hingain_permissions_rmdirmeans a symlinkedrmdirpath can no longer redirect the privileged permission changes onto whatever it points at, and the abort becomes a clean "not empty" skip.-hneeds no condition because it is a no-op on a real directory, so nothing is decided from a path that could change before the recovery runs. Real directories are unaffected.This narrows the traversal rather than closing it:
childrenand the per-directoryrmdircan still be redirected if the path is swapped between the check and the use. Doing better needs descriptor-relative traversal withO_NOFOLLOW, which Ruby cannot express without FFI and which would replacerecursive_rmdirrather than guard it. Before this change the link was followed on every run, so the window goes from certain to raced.brew benchmarkresults.brewcommands to reproduce the bug? Reproducing needs a cask naming a path a second account can replace, covered by the added specs instead.brew lgtm(style, typechecking and tests) locally?Claude Code with Opus 5, with local review and testing.