-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DEVPROD-7289 Resolve symlinks and links correctly when extracting tarballs #8574
DEVPROD-7289 Resolve symlinks and links correctly when extracting tarballs #8574
Conversation
it looks like there's a security risk involved with using absolute paths because it could potentially be abused by symlinking something they shouldn't have access to (that's what I'm assuming) should we still do this then? |
This reverts commit 7d31bff.
Hm, if it tried symlinking something they shouldn't have access to it would get permission denied. The agent app has the same permission as the user / vice versa. The issue that was lately was what you described but unintentional (it was symlinking to /<arfiact_file> rather than /<task_dir>/<artifact_file> |
Let me try out the security suggestion the code quality says (I think it is a non-problem but it can't hurt!) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the new security alert can be dealt with just by validating hdr.Name isn't something weird but it looks good ty for fixing!!!
lgtm with the tests fixed!
DEVPROD-7289
Description
This switches over to using the absolute path when extracting files
Testing
Old task has a tarball with the symlink file, the symlinked file (original) and tries to extract it. It fails with permission denied.
New tasks has two, one with it incorrectly set up with only the symlinked file (original) in the tarball, and one with it correctly with the symlink file and the symlinked file (original) which passes.