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

Symlink traversal confusion when scanning unpacked filesystems #1359

Open
jedevc opened this issue Nov 21, 2022 · 2 comments · Fixed by #1485
Open

Symlink traversal confusion when scanning unpacked filesystems #1359

jedevc opened this issue Nov 21, 2022 · 2 comments · Fixed by #1485
Labels
bug Something isn't working

Comments

@jedevc
Copy link
Contributor

jedevc commented Nov 21, 2022

Assume we have a directory containing an unpacked container image in the target directory:

$ echo "FROM alpine" | docker build -o type=local,dest=target

We could also create target.tar out of this same target directory:

$ tar cf target.tar target/*

If we scan this as a directory source, we can note a couple warning message that indicate that syft is scanning directories that weren't intended by the user:

$ syft -o spdx-json=out.json dir:./target -v
[0000]  INFO syft version: [not provided]
[0000]  WARN unable to access path="/bin/busybox": lstat /bin/busybox: no such file or directory
[0000]  WARN unable to access path="/run/brltty": open /run/brltty: permission denied
...

These warnings start to appear because of the symlinks /bin/tar to /bin/busybox and /var/run to /run. I would expect these contents to be resolved entirely within the provided path, but it seems like this behavior is intentional, though I'm not sure of the context: see https://github.com/anchore/syft/blob/main/syft/source/directory_resolver.go#L530-L532 introduced in #442.

What's even weirder to me is this behavior is identical even when scanning file:target.tar (since it shares the same directory resolver code, after unpacking it into a tmp directory):

$ syft -o spdx-json=out.json file:./target.tar -v
[0000]  INFO syft version: [not provided]
[0000]  WARN unable to access path="/bin/busybox": lstat /bin/busybox: no such file or directory
[0000]  WARN unable to access path="/run/brltty": open /run/brltty: permission denied

After raising on the community slack, @kzantow suggested a possible new source type, root-dir (or similar), where all content could be resolved internally, additionally, with the same cataloguers as the image: source (since those also differ).

@jedevc jedevc added the bug Something isn't working label Nov 21, 2022
@kzantow kzantow added this to OSS Nov 29, 2022
@kzantow kzantow moved this to Backlog (Pulled Forward for Priority) in OSS Dec 10, 2022
@kzantow
Copy link
Contributor

kzantow commented Dec 10, 2022

We still need to figure out the right solution here, but this definitely seems like something we want to support.

@kzantow
Copy link
Contributor

kzantow commented Jan 30, 2023

I'm going to leave this open until it gets implemented in Syft proper, not just the API.

@kzantow kzantow moved this from Done to Backlog in OSS Jan 30, 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
Status: Backlog
Development

Successfully merging a pull request may close this issue.

2 participants