fix: resolve symlink chains fully when extracting - #142
Conversation
Backport of #140 to 1.x. isRealPathSafe() stopped walking as soon as realpath() failed on a dangling link, checking only that link's immediate target. A destination reached through several hops, or through a linked directory, was only partially resolved, so an entry could land somewhere the check had not accounted for. Resolve the remaining hops by hand instead, bounded by MAX_SYMLINK_DEPTH, and walk from whichever extraction root actually contains the target so a link named in the real namespace is not rejected. File entries no longer write through a symlink sitting at the destination. The link is replaced by the entry, which is how tar(1), node-tar and libarchive all behave. Where the platform has it, the write also opens with O_NOFOLLOW.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
🎉 This PR is included in version 1.10.6 🎉 The release is available on: Your semantic-release bot 📦🚀 |
1 participant
Backport of #140 to 1.x.
isRealPathSafe()stopped walking as soon asrealpath()failed on a dangling link, checking only that link's immediate target. A destination reached through several hops, or through a linked directory, was only partially resolved, so an entry could land somewhere the check had not accounted for.It now resolves the remaining hops itself, bounded by
MAX_SYMLINK_DEPTH, and walks from whichever extraction root actually contains the target so a link named in the real namespace is not rejected.Behaviour change worth noting: a file entry landing on a symlink now replaces that link instead of writing through to whatever it points at. This matches tar(1), node-tar and libarchive. Where the platform has it, the write also opens with
O_NOFOLLOW. Linked directories inside the extraction directory are still traversed.Written in the callback style the surrounding 1.x code uses, so it stays compatible with the branch's Node range. Suite is 166 passing on this branch.