Resolve links/hardlinks for image scanning

[DmitriyLewen]

We currently skip links when scanning images, because archive/tar package can't read value of link.
Typically hardlink and base file use same file name, and for us this is not problem because if we missed harklink - we will parse base file.
But 1 case was found:
pnpmcan use hardlinks for package.json files from node_modules/.pnpm/... dir.
But base files doesn't use package.json filenames.
See this comment - #5332 (reply in thread).

To check links - we need to walk each tar archive (zipped layers) 2 times (to find links and read base files).
Trivy will take longer to work.

Perhaps we can add flag to enable link detection.

Welcome with out experiance, ideas, etc.

[simar7]

I think this is a wider issue that affect all kinds of scanning within Trivy. We also don't support the same in misconfiguration scanning. Please see this for context #5002

cc @knqyf263

[DmitriyLewen]

Conda also uses hardlinks - #5360

[DmitriyLewen]

If i remember correctly - symlink uses TypeSymlink

[knqyf263]

I see. Can we resolve hard links? Does it have a file path to the original file?

[DmitriyLewen]

hardlink has filepath of original. Take a look screenshot in this comment - #5332 (reply in thread)

[knqyf263]

Thanks. I was thinking about the implementation, but didn't develop a good idea. It looks stupid if we download the layer twice. Although we can download the layer to a temp file, the layer size can be a few GB. It consumes storage a lot.

[DmitriyLewen]

I was thinking about going through the layers twice:
1 - take all hardlinks (and symlinks if we need it) and save into map: main file - link
2 - It is our default run, but when we find file from map, we analyze this file and save it with several filepaths (i mean main filepath and filepaths for each links)

But it seems to take longer to scan.

[simar7]

Should we create an issue to track this @knqyf263?

[knqyf263]

@simar7 Please let me clarify the problem first. I'm still not understanding why hard links cause problems. If I understand correctly, the hard link doesn't have a base file. Hard links just refer to the same inode.

I think the problem with symbolic links is different from the one with hard links.

[manojkrishnanomula]

@knqyf263 did you conclude on how to make this approach because we're dependent on these hardlinks and symlinks as part of #5360

[knqyf263]

No, we haven't come up with a good idea yet. Please let us know if you have any ideas.
#5356 (reply in thread)