Container path may be missing path components

[nightlark]

When creating an SBOM from pieces of a container, the files may appear to be in a flat file system within the container.

e.g. A.zip has a file under usr/bin/fileA

An SBOM is generated with a config file that lists:
archive = "A.zip"
extractPaths = "some-directory-with-only-usr/bin-files"

The resulting SBOM should have fileA with a container path of <parent_uuid>/usr/bin/fileA, but it actually just has <parent_uuid>/fileA. This could potentially be inferred to some degree from the provided installPrefix? But msi/exe installers get complicated (are they just a bunch of blobs of file data internally?).

[nightlark]

Rebasing (absolute?) symlinks has issues in a similar situation.

e.g. symlnkA -> /usr/bin/fileAwith an extract path with only files in usr/bin that doesn't also replicate the usr and `bin folders within it results in these lines messing up:

# Rebase to get the true location
current_path = os.path.join(extract_dir, dest)

current_path becomes something like <extract_path>/usr/bin/fileA... which doesn't exist because it is just <extract_path>/fileA on the system that is doing the analysis.

A possible fix could be assuming that the layout for the extracted files and created symlinks were pulled directly from the system they run on, and that installPrefix can be used to pull out the part of the path that should not be replicated.

[nightlark]

OK, the fix for the symlink resolving works -- however, if files from the same folder (e.g. /usr/bin) (or separate folders such as /bin or /sbin) have been split up into multiple extractPaths, the resolver doesn't consider files in those other directories.

The only way I could see to fix this would be to internally create a "file system mapping" of which installed directory different extract paths map to (one to many). Which gets into more complex questions about how to do SBOMs with files from different systems.

[nightlark]

A "quick" solution to address the remainder of this issue could be adding a containerPath option that specifies a path that should go between the container UUID and the relative paths for files within the extractPaths. Or users can just replicate the directory structure they want it to have in the container by having some nested folders.

I think a separate issue for refactoring Surfactant to use data structure that maps better to a file system hierarchy, and adds a mechanism to the config file to specify a unique ID representing the filesystem a particular config file entry "installs to" will be needed -- if none is specified, everything would be placed under a default filesystem ID. Resolving relationships would then be given a FS tree/hierarchy to consider, and that would avoid establishing links to files not on the same filesystem. This could also punt resolving symlinks until a structure with all the fragments from separate extract paths has been created.