On Sat, 01 Feb 2025 at 21:45:32 +0000, Sean Whitton wrote: > On Fri 31 Jan 2025 at 08:24pm GMT, Simon McVittie wrote: > > Podman-, Toolbx- and Distrobox-friendly OCI images can be created from > > any suitable tarball (autopkgtest-build-podman(1) includes an example of > > using it to make an image from first principles using mmdebstrap) and do > > not require interacting with a third-party container registry. > > Thanks. Do these tools want to use tarballs and/or container registry > images, or can I use them with plain chroots? That would make migration > easier. (I have custom chroot builders, and they don't know how to pack > and unpack tarballs, yet.)
The conventional code path for these tools is to use OCI images, which are a stack of filesystem layers as would be used for overlayfs, plus metadata. In Podman they are normally stored as a directory on disk in ~/.local/share/containers/storage with high-numbered uids (from /etc/subuid), and transferred between machines as a series of tarballs (intentionally the same format Docker uses). I think perhaps when you say "container registry" here, you really mean OCI images. A container registry is a remote storage area for OCI images accessed via https (analogous to a http:/https: apt repository). There is no obligation to use a container registry, it is equally valid to have OCI images that only exist locally (more like a file: apt repository). Podman identifies these images with a localhost/ prefix, but is not actually accessing a container registry on https://localhost (it's only a notation used to represent its local storage). `podman run --rootfs` exists, but it is not the normal code path and I don't use it myself. I suspect that it requires the on-disk rootfs to have high-numbered uids from /etc/subuid, too. I don't think the higher-level convenience tools (Toolbx or Distrobox) support it. Anything that uses user_namespaces(7) and /etc/subuid to allow entering a container with multiple uids, while not being root-equivalent, is inherently going to need to either use a tar-like archive as its persistent storage (like the unshare backends for mmdebstrap, sbuild and autopkgtest do), or store the container files with your high-numbered uids (like podman does, and I believe unprivileged lxd/incus do the same). This is perhaps not immediately obvious, but if you think about it you'll realise that you can't read and write files that are owned by "real root" without being root-equivalent (as you would with schroot, lxc, Docker and systemd-nspawn). The only containers based on user_namespaces(7) that don't need to use weird high uids somewhere are the ones created by bwrap(1) and similar tools (as used in Flatpak and web browsers), which only have two uids visible, your own uid and the kernel's overflowuid (to be read as "me" and "not me" respectively). Those are fine for leaf applications (the Flatpak use-case) and highly constrained sandboxes (the browser use-case), but are not flexible enough to allow a container that behaves like a full system, which is what we generally want in autopkgtest. smcv
