fix: handle existing symlinks in ForbiddenPathError check #2334
+46
−1
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.
Description
Fixes #2333 - Resolves
ForbiddenPathErrorbeing incorrectly raised for legitimate external symlinks duringcopier update.Problem
The current security check resolves symlinks before validating whether paths are within the destination directory:
This causes false positives when destination directories contain symlinks pointing outside the project (e.g.,
.env.local→ external secrets directory), as.resolve()returns the external target path rather than the symlink path itself.Solution
This PR modifies the security check to detect existing symlinks before resolution:
Testing
test_symlink_to_external_path_does_not_raise_forbidden_errorUse Cases Enabled
This fix enables common legitimate patterns:
.env.local→ external secrets directoryBackward Compatibility
Related
See issue #2333 for detailed problem analysis and reproduction steps.
Thank you for reviewing this fix! I tried to be conservative in the approach to maintain the security intent while resolving the symlink issue. Please let me know if you'd like any adjustments.