Skip to content
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

Generic Worker evaluates absolute paths as relative in mounts and artifacts #6689

Open
petemoore opened this issue Nov 16, 2023 · 0 comments · May be fixed by #6690
Open

Generic Worker evaluates absolute paths as relative in mounts and artifacts #6689

petemoore opened this issue Nov 16, 2023 · 0 comments · May be fixed by #6690
Assignees
Labels
bug Something isn't working

Comments

@petemoore
Copy link
Member

petemoore commented Nov 16, 2023

There is a bug in Generic Worker which occurs when a task payload specifies an absolute path to an artifact, or an absolute path to a file or directory inside a mount. Instead of respecting the provided path, Generic Worker effectively strips any leading slash and then evaluates the path as a relative path from the task directory. This is due to it internally using go's filepath.Join function which has this behaviour:

filepath.Join(<task directory>, <provided path>)

Instead, Generic Worker should first check if the provided path is absolute, and only join it to the task directory if it is not.

Note absolute paths are useful for e.g. mounting under /usr/local/bin or e.g. publishing artifacts from files inside /var/log and since mounting/publishing artifacts is performed as task user, there is no reason to forbid absolute file locations. The OS already limits where the (unprivileged) task user can read/write, and the task commands also are not subject to such restrictions.

Of course relative paths are still supported, and are expected for files inside the task directory (since task author cannot predict what the task directory path will be), and paths are allowed to start with e.g. ../ if really desired, since they do not pose any additional security risk.

@petemoore petemoore added the bug Something isn't working label Nov 16, 2023
@petemoore petemoore self-assigned this Nov 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant