Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access rootful containers storage #515

Open
p5 opened this issue Feb 13, 2025 · 2 comments
Open

Access rootful containers storage #515

p5 opened this issue Feb 13, 2025 · 2 comments
Labels
enhancement New feature or request

Comments

@p5
Copy link

p5 commented Feb 13, 2025

What would you like to be added:

As a follow-up to the discussion around UBlue images and SBOM scanning from the livestream earlier today, I'd like to propose an additional input parameter to the action which runs syft as a rootful user, giving it access to resources only accessible to root.

After some debugging,

Something as simple as

- uses: anchore/sbom-action@v0
  with:
    image: my-registry.com/my/image
    rootful: true

This could even be more intelligent - "if the rootful Podman socket is detected, check if the image is present". That way, we don't need to add any new input parameters to the action.

Why is this needed:

Sometimes it's useful to run Podman builds as a rootful user (i.e. with sudo), which stores images in a different location to when it's ran with non-root users. Currently the sbom-action runs Syft as the regular GitHub Actions user, so Syft cannot reach out to the rootful container storage required when Podman is ran as sudo.

When building images with Docker, this is not an issue since the same storage is used for root and rootless users by default.

Additional context:
I'm happy to look into implementing this feature request if the Anchore team is okay with the suggestion.

@p5 p5 added the enhancement New feature or request label Feb 13, 2025
@p5
Copy link
Author

p5 commented Feb 13, 2025

As to the question around "why use sudo"?

Podman runs in a different (and safer) way to Docker. If you want Podman to do certain things like those required by the custom "rechunk" step mentioned, you need to be running as a rootful user (exactly what those things are, I'm not familiar).
That means we either run the build as a non-root user and copy the image over to the rootful container storage (which we tried but end up running into storage limitations in the GitHub Actions runners), or we simply run the initial build as root - what we are doing.

Podman runs in a different (and safer) way to Docker.

Elaborating slightly - Docker is more vulnerable to privilege escalation by anybody in the "docker" group. If they can escape the container, they will have root permissions on the host. Since Podman separates containers running from the root and non-root users, users are unable to break into root if they escape the container from a non-root container.

While Docker typically runs containers as the root user, Podman allows for rootless containers. This enhances security, especially in multi-tenant environments or on shared systems. Rootless containers also provide an easier approach to orchestrating containers with less risk of privilege escalation.
(Source: Some Google AI summary)

This isn't me advocating for using one over the other - it's purely an explanation why this issue is necessary, and why the builds are using sudo.

@kzantow
Copy link
Contributor

kzantow commented Mar 5, 2025

Hi @p5, this looks like something that we could accept a PR for if you were willing to make and test the change for your use case. It looks like we would just need to adjust the exec call, and add an option as you noted.

@kzantow kzantow moved this to Ready in OSS Mar 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Ready
Development

No branches or pull requests

2 participants