Skip to content

fix(cookbooks): keep downloads inside destDir through an os.Root - #113

Merged
tas50 merged 1 commit into
mainfrom
fix/cookbook-download-os-root
Oct 13, 2026
Merged

tas50 merged 1 commit into
mainfrom
fix/cookbook-download-os-root

Conversation

@tas50

@tas50 tas50 commented Oct 13, 2026

Copy link
Copy Markdown
Collaborator

Summary

Cookbooks.DownloadFiles (and Download) checked each manifest path lexically, so ../x was refused. But it then trusted the filesystem it wrote into. A symlink already under destDir that pointed elsewhere carried the write with it: with recipes -> /elsewhere, the manifest's clean recipes/default.rb landed in /elsewhere/default.rb. A file that was itself a symlink out of destDir was read through for the "already up to date" check; when its target happened to match the checksum, the link was left in place instead of a real file.

A manifest cannot create symlinks, so this needs a pre-existing link in the destination (a shared or reused checkout, say). It's defense in depth rather than a remote exploit. os.Root (Go 1.24, with MkdirAll/Rename since 1.25) is the standard-library tool for exactly this.

Change

  • Writes go through os.OpenRoot(destDir): the checksum read, MkdirAll, temp file and final rename are all held under destDir by the OS, not by string checks.
    • A symlinked directory pointing out of destDir fails the download, and nothing is written outside.
    • A symlinked file pointing out is no longer trusted as a cached copy. It's fetched and replaced by a real file; the link's target is untouched.
    • A symlink that stays inside destDir is followed as before.
  • Manifest paths are checked up front with filepath.IsLocal (equivalent to the old filepath.Rel check, and it also refuses Windows reserved names). A bad manifest still fails before anything is fetched.
  • The temp file's 0644 mode is set with File.Chmod on the open handle. Root.Chmod by name is documented as racy on Unix.
  • destDir is created up front if missing (it was created implicitly before), and a destination that can't be created or opened fails before any fetch.
  • The DownloadFiles doc comment states the new guarantee. No signature change.

Test plan

  • New, red before the change: TestDownload_RefusesSymlinkedDirectoryOutOfDest (the file was written outside), TestDownload_ReplacesSymlinkedFileOutOfDest (an outside link was kept as a cached copy)
  • New guards: TestDownload_FollowsSymlinkWithinDest, TestDownload_DestinationUnusable (destination is a file; destination can't be opened)
  • Existing download tests unchanged and passing: traversal rejection, checksum mismatch and skip, truncated body leaves the destination intact, 0644 mode, filesystem failures with their error messages
  • Every changed function at 100% line coverage; package 98.1% → 98.2%
  • go test ./... -race -count=2, cd integration && go test ./... (HTTP and TLS cookbook round-trips), golangci-lint run ./... in both modules

DownloadFiles checked manifest paths lexically, so a path could not climb
out of destDir, but the filesystem it then wrote into was trusted: a
symlink already under destDir that pointed elsewhere carried the write
with it. With recipes -> /elsewhere, recipes/default.rb landed in
/elsewhere. A file that was itself a symlink out of destDir was read
through for the up-to-date check and, when its target had the right
checksum, left in place.

Writes now go through os.OpenRoot(destDir): the checksum read, MkdirAll,
temp file and rename are all held under destDir. A symlink pointing out
fails the download (a directory) or is replaced by the downloaded file (a
file); one that stays inside destDir is followed as before. Manifest paths
are checked with filepath.IsLocal up front, so a bad manifest still fails
before anything is fetched. The temp file's mode is set on the open file
rather than by name.

Signed-off-by: Tim Smith <tsmith84@proton.me>
@tas50
tas50 merged commit 7d8fbbb into main Oct 13, 2026
6 checks passed
@tas50
tas50 deleted the fix/cookbook-download-os-root branch October 13, 2026 11:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant