opa build constructs bundle with absolute paths
kbalthaser opened this issue · 6 comments
Short description
Version: 0.58.0
When running the opa build -b somepath CLI command, the resultant bundle file is constructed with absolute paths on the files. This tar file could then trigger path-traversal issues when being decompressed. This also doesn't match what is seen in the description of the bundle file format: https://www.openpolicyagent.org/docs/latest/management-bundles/#bundle-file-format
Steps To Reproduce
$ ls foo
example.rego
$ opa build -b foo
$ tar -tf bundle.tar.gz
/data.json
/foo/example.rego
Expected behavior
Expect that the tar file does not contain absolute paths to filesystem root.
Ex:
$ tar -tf bundle.tar.gz
data.json
foo/example.rego
Hi @kbalthaser! Thanks for reporting that. It does seem like an issue either in the docs or how the bundle is built. Could you perhaps help me understand what kind of path-traversal issues this may result in?
The path-traversal issue is usually on the python side, which has mostly been fixed at this point. That said some packages still have a check in place and will refuse to decompress a file that contains absolute paths in the tar file, in our case OPAL will refuse to decompress the bundle. If the community here thinks there is no issue with the bundler on the OPA side, I can certainly talk with the OPAL developers as well.
I think it is just strange to see the tool build the bundle with the files pathed to root, it is not really what you would normally see on a standard tarball archive. As such it just "looks" and "feels" like it is incorrect. You would normally have to go out of your way to construct the archive like that. I would like to understand the reasoning behind having the bundle packaged with that leading / on all files.
I don't know if there was any conscious reasoning behind that, and we'd have to go back to 2019 to ask :)
https://github.com/open-policy-agent/opa/blob/main/internal/file/archive/tarball.go#L30
In the time since, I've never since this raised as an issue, but presumably few tools other than OPA do more work on bundles than to serve them. For that reason, I'd be weary of making changes to the format at this point in time, but I'd be happy to see the docs updated to reflect how they're stored in the archive.
Frankly, it's always been like that and I, too, never questioned it. I don't think there's a good reason for it to be like it is, and it's also unlikely to break much stuff when we change it. However, I do have used explicit un-tar calls before, like tar xf bundle.tar.gz /policy.wasm, and so have others -- those would break if we remove the leading slash, I think.
Looking around, there would be a few people affected, it seems: https://github.com/search?q=%22%2Fpolicy.wasm%22&type=code
With that much inertia, I can understand not wanting to change it at this point. I can pretty easily work around this issue by repacking the archive.
Thanks @kbalthaser 👍 I'll close this then. If others experience issues around this, they should hopefully be able to find this discussion.