RPM Scanner does not work on layers where /var/lib/rpm is a symlink

[pnasrat]

What happened:

I was testing the RPM scanner functionality and noticed it was returning no packages on recent Fedora images (36+), compared to running generate on debian images.

Here testing with fedora 38 amd64 image quay.io/fedora/fedora@sha256:3a1fa4954928d6b8244b36c5de3b6f30d7e6b55227f4f329bba1125a093ae4f9

 go run cmd/bom/main.go document outline fedora.spdx 
               _      
 ___ _ __   __| |_  __
/ __| '_ \ / _` \ \/ /
\__ \ |_) | (_| |>  < 
|___/ .__/ \__,_/_/\_\
    |_|               

 📂 SPDX Document SBOM-SPDX-0b877dd8-cbed-4a1e-9229-20c04c0f3ef2
  │ 
  │ 📦 DESCRIBES 1 Packages
  │ 
  ├ sha256:3a1fa4954928d6b8244b36c5de3b6f30d7e6b55227f4f329bba1125a093ae4f9
  │  │ 🔗 1 Relationships
  │  └ CONTAINS PACKAGE sha256:b30887322388a8cac2870fb8c3967da520319cb02219923e87b60ca980ccb572
  │ 
  └ 📄 DESCRIBES 0 Files

Analysis

Recent Fedora and derived distributions have made /var/lib/rpm a symlink to ../../usr/lib/sysimage/rpm

This will also be broken on OSTree images and recent SUSE, and probably future RHEL

See https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr

The current rpmdb extraction code checks that the full rpmdb (eg var/lib/rpm/rpmdb.sqlite) path exists in the tar, however if var/lib/rpm is a symlink the existence check will failhttps://github.com/kubernetes-sigs/bom/blob/main/pkg/osinfo/scanner_rpm.go#L67

I'm happy to create a PR to fix this

What you expected to happen:

Fedora RPM packages to be included in the generated spdx file

How to reproduce it (as minimally and precisely as possible):

1. go run cmd/bom/main.go generate --output=fedora.spdx --image quay.io/fedora/fedora@sha256:3a1fa4954928d6b8244b36c5de3b6f30d7e6b55227f4f329bba1125a093ae4f9
2. go run cmd/bom/main.go document outline fedora.spdx

/kind bug

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[puerco]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale