New path filtering logic excluding large number of unintended paths

[jpalermo]

What happened:
#2644 introduced new logic to prevent scanning of unixSystemRuntimePrefixes even if those paths are not at the root, for example remounted root file systems. The solution however prevents scanning any paths that include a /proc, /dev or /sys within them. For example:
folder/syslog-scan.sbom.json
source_code/system/files
source_code/dev/other_files
are all skipped after this change.

What you expected to happen:
Only /proc, /dev and /sys that are part of fs roots should be excluded, not anything including those strings.

Steps to reproduce the issue:
Attempt to scan an sbom file that starts with the string sys

Anything else we need to know?:

Environment:

• Output of syft version: 0.105.0
• OS (e.g: cat /etc/os-release or similar): Any

[klakin-pivotal]

I wonder if a better way to handle this sort of exclusion would be to (when initializing/starting the scan) find filesystem paths that have devtmpfs, sysfs, and proc types and exclude those paths and their children, rather than assuming that any directory named sys or proc or dev MUST contain a kernel-managed pseudo-filesystem that's okay to exclude from scans.

[wagoodman]

I like the suggestion to look for forbidden mounts instead of leaning on mount naming conventions. We can't revert this PR since we have had other users that are mounting these filesystems within nested directories. That doesn't explain away the reason for reverting this though... I think there are unintended consequences.

@jpalermo / @klakin-pivotal would either of you be interested in implementing the suggestion within the file resolver for finding forbidden filesystems first?

[jpalermo]

It seems like the "correct fix" for the original problem is incredibly difficult, so somebody who wants it should work on it. An alternative is people who are scanning mounted images can exclude the paths they don't want scanned.

As far as not reverting, the current syft is in a very bad state because of the original PR. Large chunks of code bases are currently being excluded accidentally, meaning the generated sboms are incorrect.

[klakin-pivotal]

I'm not interested in implementing the proper zero-false-exclusions version of the "Don't scan kernel pseudo-filesystems because we know that there are no artifacts we care about in there" code. Conceptually it's not tough to do, but I've no knowledge of how the filesystem scanner code works.

Even a version of the code in the PR that just scans for directories named sys, proc, dev is inevitably gonna end up falsely excluding artifacts in someone's codebase.

[wagoodman]

No worries! I wanted to offer it up in case there was interest --I can take a stab at this later this week.