M0x41-podman - Unofficial Podman Snap Package

store-requests classic-confinement
1

Request

Podman is a daemonless container engine used for developing, managing, and running OCI containers. Analogous to Docker. It requires host filesystem access for setuid binaries, library path propagation, and systemd generator registration, none of which are achievable under strict confinement.

I understand that strict confinement is generally preferred over classic.

I’ve tried the existing interfaces to make the snap to work under strict confinement.

Rationale

As the upstream project is mature and popular to which I have no formal relationship, I have no means to adapt it to meet the confines of Snap, therefore this is more of an attempt utilise Snap features to enable Podman to work within these constraints.

Strict confinement’s mount namespace replaces /usr/bin with the base snap’s copy, which breaks both rootless and rootful container operation through four fundamental constraints:

1. setuid newuidmap/newgidmap unreachable

The host’s setuid binaries (from the uidmap package) are hidden by the mount namespace. Staging them inside the snap does not work: snapcraft strips setuid bits during packing, squashfs mounts with nosuid, and file capabilities are also stripped. Without these binaries, rootless user namespace creation fails outright.

2. netavark path resolution failure

Podman discovers its network backend (netavark) via helper_binaries_dir, not the netavark_path configuration key. Under strict confinement the bundled binary cannot be found, so all container networking fails.

3. LD_LIBRARY_PATH lost across process boundaries

The snap wrapper sets LD_LIBRARY_PATH for Podman, but when Podman spawns conmon, which then spawns crun, the library path is not inherited. Bundled libraries such as libyajl (required by crun) are not found, causing every podman run to fail with an OCI runtime error.

4. policy.json path cannot be changed

Podman hardcodes two filesystem paths for policy.json and provides no environment variable override. Under strict confinement the snap cannot place the file at either expected location.

These four constraints block container execution in both rootless and rootful modes. No combination of existing snapd interfaces (system-files, personal-files, layouts, snapcraft-preload) resolves all four simultaneously. The system-files interface cannot grant access to setuid binaries. Layouts cannot inject files into paths owned by the base snap. The library path propagation issue occurs across process boundaries that snapd does not appear to control.

5. Snap runtime directory not created for non-interactive sessions

su - does not trigger a logind session, so snapd never creates /run/user/<uid>/snap.<snap-name>, breaking rootless operation when invoked via su or sudo -u.

6. Install hook cannot modify the host

Classic confinement enables the snap’s install hook to register systemd generators for Quadlet (systemd container integration) and place a podman shim on PATH at /usr/local/bin/podman. These operations write to /usr/lib/systemd/, /usr/local/bin/, and /etc/ld.so.conf.d/ — all prohibited under strict confinement. Without them, Quadlet does not work and users must invoke the snap by its full name rather than podman.

One of the key changes to v5 of Podman is the ability to orchestrate pods using Quadlets relative to v4 (currently in Ubuntu 24.04).

Please examine the public source repo for the full methodology and findings.

2

@store-requests-bot manual review requested - any update?

3

Hey @miah0x41

Please note that classic confinement is a sensitive matter and it is reserved for the official upstream (in case of mature,well-known applications) and/or trusted groups, such as snapcrafters.

Thus, we cannot proceed with this request.

Thanks for your understanding

4

Thank you @jslarraz for the prompt response.

Whilst I can understand the position, I’d like to point out this particular reason is not reflected in the Classic Confinement Category post embedded in the template nor from any public documentation I could find.

I’d be grateful if you could point me towards where this policy has been made public?

The context here is that having expended significant engineering effort to get it to work on the basis there was no public blocker, I am understandably disappointed with this response.

I’d like to point out that a podman snap already exists on the store.

Finally, I’m not fussed as to who publishes the snap, the upstream repo is Apache 2.0 for that reason. Given previous attempts by snapcrafters to package this application were unsuccessful, can you ask your fellow snapcrafters if they are willing to now examine this work as a basis for their own?

5

Hey @miah0x41

The Process for reviewing classic confinement snaps consists on the following steps:

1. the publisher makes the request for classic confinement in the forum using the store-requests category
2. the technical reasons for why the snap uses classic confinement are gathered in the forum post and captured for potential future snapd improvements. The technical requirements will be reviewed by the security team and/or an architect
3. the advocacy team, reviewers team and/or architects participate in vetting the snap/publisher
4. once the publisher has been vetted, the technical reasons are captured and the request is approved, a store reviewer will issue a snap declaration for the snap and add a comment to the store, giving the URL to the forum post

Please note that classic confinement is a sensitive matter and it is reserved for the official upstream (in case of mature,well-known applications) and/or trusted groups, such as snapcrafters.

This requirement can be found in the Process for performing snap publisher vetting.

The context here is that having expended significant engineering effort to get it to work on the basis there was no public blocker, I am understandably disappointed with this response.

I fully understand the situation, and I think podman would be a great addition to the snap store. I’m not part of snapcrafters or have any formal relation with them (besides being part of the same ecosystem). Perhaps you could ask snapcrafters if they are willing to take over in snapcrafters - snapcraft.io?

Thanks

6

Thank you for the clarification and your patience with me.

I have disconnected my repo from your build servers and will de-register the app name.

As you suggest, I will ask the snapcrafters directly.

1 Like
7

And this is neither classic nor ever released to any stable channels since 2020 (in fact it looks like just an initial test that was never moved forward):

ogra@anubis:~$ snap info podman
name:      podman
[…]
channels:
latest/stable:    –
latest/candidate: –
latest/beta:      –
latest/edge:      0.11.1.1 2020-06-25 (389) 37MB devmode
ogra@anubis:~$

In the end I would expect such a snap to have its own interface and not be granted classic ever. So you have at least some mediation going on, just like lxd or docker are not classic but use dedicated interfaces for spawning their own runtime as well as for providing outside apps access to the functionality they provide…