Allow scanning unpacked container filesystems

[jedevc]

🐛 Fixes #1359 🎉

This PR is an attempt to explore how to modify the existing directory resolver to allow for resolving symlinks in an unpacked container filesystem. To do this, we add a new optional base parameter for the directory resolver that resolves all symlinks relative to this base. There are two intended use cases:

• base = "/". The previous behavior, symlinks are resolved relative to the root filesystem.
• base = path. Symlinks are resolved relative to the target filesystem, allowing correct behavior when scanning unpacked container filesystems on disk.

Currently, this only modifies the API surface for the source, which would probably be sufficient for my use case in buildkit-syft-scanner.

I've marked this as in-draft since I've only done some preliminary testing, but the following things probably need working out before this could be ready:

• Extend this to the CLI with a root-dir input type, or similar? Not quite sure on naming, I don't have any particular preference here.
  • Update: planned for follow-up
• Add tests for the new directory resolver behavior. The logic seems sound to me, but I may have missed something - thankfully, the symlink resolution seems isolated to a couple of places.
  • Update: tests added
• I've temporarily replaced filepath.EvalSymlinks with cfs.RootPath from containerd/continuity. The logic of these functions is fairly similar, however, the containerd equivalent allows bounding the result to a specified directory.
  This logic is only needed for 1 of the symlink resolution components - the other is much simpler, since syft does the heavy lifting. I'm not sure how the maintainers feel about adding this as a new dependency? Maybe there's a simpler solution I'm not seeing 👀
  Update: I can remove this dependency, since we can avoid this second instance of doing symlink resolution - we can just use the file tree that we've already indexed over, which should be more efficient anyways. I think that this is a valid use? It seems to work in the cases I tried it on.

cc @wagoodman @kzantow

[kzantow]

@jedevc it looks like you might just need to update a test (the ID is calculated based on the fields in the struct and one was added): https://github.com/anchore/syft/actions/runs/3958281654/jobs/6779661340#step:7:165

[wagoodman]

nice improvement 👍 this additionally further leverages the already built indexes which helps some upcoming PRs regarding performance boosts

[cburgess]

Would love to the see this feature make it to the CLI. We have a use case for wanting to run syft on a root filesystem and have it work just like syft does against an existing docker image today.

[jedevc]

I don't currently have the bandwidth to go and add the feature, but it should be a fairly simple plumbing exercise now that the underlying code is there, so happy for someone else to pick that up 🎉